[XeTeX] Fwd: xdvipdfmx doesn't seem to respect PDF crop areas

[Bruno Voisin]

I'm forwarding these to Gerben Wierda (the developer of i-Installer)  
in case he is no longer a member of this list.

Bruno Voisin


> De : Zachary Pincus
> Date : 22 septembre 2006 10:55:41 HAEC
> À : Unicode-based TeX for Mac OS X and other platforms
> Objet : Rép : [XeTeX] xdvipdfmx doesn't seem to respect PDF crop areas
>
>>>> Unfortunately, when I use xelatex with the xdvipdfmx driver, the
>>>> crop
>>>> area is not respected for the PDF figures included with
>>>> \includegraphics or with \XeTeXpdffile. If I use "regular"
>>>> xelatex or
>>>> plain latex, things work fine.
>>>
>>> What happens if you use dvipdfm.def instead of xetex.def
>>> by writing as
>>> \usepackage[dvipdfm]{graphicx}
>>> \usepackage[dvipdfm, ...]{hyperref}
>>> and creating .bb file for each pdf by
>>> ebb -c foo.pdf
>>> before compiling by xelatex.
>>
>> Thanks for the suggestion.
>>
>> I'll let you know how this goes as soon as I get a new ebb compiled.
>> (There are some dependencies that I don't have... No kpathsea library
>> from the i-installer (OS X tex package) version of tex,
>
> Well, this was quite a bit of fun.
>
> For posterity, in case anyone ever needs to do this again: the i-
> installer version only has the kpathsea headers and libs if you
> install the 'full' TeX, not the 'basic' one. Next, the kpathsea
> headers seem vaguely broken in that if the preprocessor symbol
> 'HAVE_PROTOTYPES' is not externally defined, then gcc chokes on them.
> (This was tricky to find since the gcc barf was hidden by the
> configure script for dvipdfm.) So finally by setting CFLAGS to '-
> DHAVE_PROTOTYPES', I got ebb to compile. At which time I found that
> ebb only works for PDF versions 1.3 and below.
>
> After converting a test figure to 1.3 from 1.4 and creating a
> bounding box file and re-running xelatex+xdvipdfmx... nothing
> changed. The bounding box is ignored.
>
> I'm including the figure with '\includegraphics{figure}', and the
> files 'figure.pdf' and 'figure.bb' are next to eachother in the
> filesystem. graphicx and hyperref are both configured to use dvipdfm.
> The xelatex output doesn't hint at anything amiss.
>
> So maybe xdvipdfmx is disregarding the bounding box info from .bb
> files too? Let me know if I can test anything further, and thanks
> Akira and Jonathan for the help and suggestions!
>
> Zach


> De : Akira Kakuto
> Date : 22 septembre 2006 12:47:55 HAEC
> Objet : Rép : [XeTeX] xdvipdfmx doesn't seem to respect PDF crop areas
>
>> For posterity, in case anyone ever needs to do this again: the i-
>> installer version only has the kpathsea headers and libs if you
>> install the 'full' TeX, not the 'basic' one. Next, the kpathsea
>> headers seem vaguely broken in that if the preprocessor symbol
>> 'HAVE_PROTOTYPES' is not externally defined, then gcc chokes on them.
>> (This was tricky to find since the gcc barf was hidden by the
>> configure script for dvipdfm.) So finally by setting CFLAGS to '-
>> DHAVE_PROTOTYPES', I got ebb to compile. At which time I found that
>> ebb only works for PDF versions 1.3 and below.
>
> Formally higher version will be allowed by rewriting the function
> pdf_set_version() in pdfobj.c like
>
> static unsigned pdf_version = 4;
> void pdf_set_version (unsigned version)
> {
>   if (version >= 2 && version <= 7) {
>     pdf_version = version;
>   }
> }
>
>> So maybe xdvipdfmx is disregarding the bounding box info from .bb
>> files too? Let me know if I can test anything further, and thanks
>> Akira and Jonathan for the help and suggestions!
>
> Please note the option [dvipdfm]:
> \documentclass[dvipdfm]{article}
> ... ...
>
>
> If you set the [dvipdfm] option as above, compilation itself
> by xelatex must fail if foo.bb is missing.
>
>
> Best regards,
> Akira