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

[Zachary Pincus]

Hi all; sorry if this is noise to anyone.

There are two kpathsea issues here: (1) is that it is only included  
in the 'full' i-installer package. This seems reasonable. (2) is the  
strangeness with the headers.

It turns out that the kpathsea headers work fine if they are used  
correctly. The dvipdfm configure script and code files do *not* use  
them correctly! This has nothing to do with kpathsea in general or  
the i-installer version. Basically, kpathsea.h should be included  
when using kpathsea, not any specific other file. (Or in the latter  
case, care must be taken to first load the configuration headers like  
config.h and c-auto.h.) The dvipdfm sources do not do this, causing  
trouble.

OK, back to the regularly-scheduled broadcast. (Is anyone involved  
with dvipdfm who could mention this to the right people?)

Zach


On Sep 22, 2006, at 7:59 AM, Bruno Voisin wrote:

> 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
> _______________________________________________
> XeTeX mailing list
> postmaster at tug.org
> http://tug.org/mailman/listinfo/xetex