[XeTeX] placing and colouring a graphic

[Jonathan Kew]

On 22 Aug 2008, at 12:35 PM, William Adams wrote:

> My hope was that just setting the colour and placing the 1-bit graphic
> would be sufficient,

I doubt that would work, though I confess I haven't tried it. But I  
wouldn't expect graphics (of any kind) to be affected by the color  
specials.

> but that fails w/ the error:
>
> (./ADA006-LVL1-MA-BL.aux) <use  "ADA006-LVL1-MA-BL.TIF" >
> Overfull \hbox (51.09396pt too wide) in paragraph at lines 8--10
> []\OT1/cmr/m/n/10 test []
> [1] (./ADA006-LVL1-MA-BL.aux)Error: /undefined in MM

(see below for explanation of this)

>
> Operand stack:
>
> Execution stack:
>    %interp_exit   .runexec2   --nostringval--   --nostringval--   --
> nostringval--   2   %stopped_push   --nostringval--   --
> nostringval--   --nostringval--   false   1   %stopped_push   1813
> 1   3   %oparray_pop   1812   1   3   %oparray_pop   1808   1   3
> %oparray_pop   1691   1   3   %oparray_pop   --nostringval--
> %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --
> nostringval--   2   %stopped_push   --nostringval--
> Dictionary stack:
>    --dict:1092/1123(ro)(G)--   --dict:0/20(G)--   --dict:69/200(L)--
> Current allocation mode is local
> Current file position is 3
> GPL Ghostscript 8.57: Unrecoverable error, exit code 1
>
> ** WARNING ** Filtering file via command -->gs -q -dNOPAUSE -dBATCH -
> sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 -
> dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -
> dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -
> dUseFlateCompression=true -sOutputFile=/var/folders/qq/
> qqznv9WRGEGflSBYT6SmnE+++TQ/-Tmp-//dvipdfmx.PkXNiH ./ADA006-LVL1-MA-
> BL.TIF -c quit<-- failed.
> ** WARNING ** Image format conversion for "./ADA006-LVL1-MA-BL.TIF"
> failed...
> ** WARNING ** Image width=0.0!
> ** WARNING ** Image height=0.0!
> ** ERROR ** pdf_ref_obj(): passed invalid object.
>
> So I'm wondering if it's even possible to place a 1-bit graphic in
> xetex using xdv2pdf and Apple's pdf rendering technology.

That looks like xdvipdfmx, not xdv2pdf. Two clues: xdv2pdf would never  
run ghostscript to try and convert a graphic, and the WARNING and  
ERROR messages at the end are distinctively xdvipdfmx messages.

I guess you're using a post-TL2007 version of xetex, where xdvipdfmx  
is now the default output driver; if you want to use xdv2pdf, you'll  
need to specify it explicitly with the -output-driver option (or  
create an .xdv file and process it manually).

xdvipdfmx doesn't support tiff, and it's default treatment of  
"unknown" graphics (inherited from dvipdfmx) is to try and process  
them as postscript, using gs (or whatever the cfg file says). That  
accounts for the ghostscript errors you see.

JK