[XeTeX] XeTeX/xdvipdfmx or the driver bug with eps images
zdenek.wagner at gmail.com
Wed May 28 17:25:36 CEST 2014
2014-05-28 16:04 GMT+02:00 Philip Taylor <P.Taylor at rhul.ac.uk>:
> Vafa Karen-Pahlav wrote:
> I also have experienced some strange problems with recent versions of
>> xetex; include an image in a document on Windows and the result is
>> perfectly fine but you try to compile the same document on a different
>> operating system, then images are placed strangely (i.e. the image width
>> exceeds the textwidth and is placed on the right or left hand side).
>> This issue is very annoying and existed for few years now. I try to send
>> some minimal example for this later today.
> Images are indeed apparently treated as second-class citizens by XeTeX,
> and I have found that the most reliable way to embed them is to embed
> them within an \hbox (or possibly a \vbox : not convinced I have tried
> the latter) and then use the resulting \box (or \copy) in lieu of the
> \XeTeXpicfile itself. \XeTeXpdffile does not seem to suffer from
> similar problems and requires no prior embedding before deployment.
TeX does not know how to use images. It can only be done via \special. With
some graphics formats it is possible to write a macro that can extract the
size. Inclusion is done by the driver, in case of XeTeX it is xdvipdfmx.
However, xdvipdfmx can include PDF, not EPS. If you wish to include EPS,
xdvipdfmx asks ghostscript to convert EPS to PDF. Thus the difference is
not in XeTeX, not in xdvipdfmx, but in ghostscript. Unfortunatelly many
programs create EPS which are not EPS according to the specification but
they often work. These nonconformant files may give different results with
different versions of ghostscript. Try Akira's suggestion, it might be
> Philip Taylor
> Subscriptions, Archive, and List information, etc.:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the XeTeX