[XeTeX] XeTeX/xdvipdfmx or the driver bug with eps images

[Vafa Karen-Pahlav]

Thanks all for the answers. As suggested by Akira and Herbert, I edited eps
image. The result with xelatex is ok but the result with latex+dvips+ps2pdf
is not ok (it is out of the \fbox). I have attached the generated pdf file.
It seems a bit odd; they behave differently.


On Thu, May 29, 2014 at 10:45 AM, Akira Kakuto <kakuto at fuk.kindai.ac.jp>wrote:

> Dear Heiko,
>
>  `epstopdf' does not require that the PostScript file is a strict
>> Encapsulated PostScript file. It takes the BoundingBox it can find,
>> moves the graphics to the origin, sets the new media size
>> (setpagedevice) and calls ghostscript for the conversion to PDF.
>> In the case that the PostScript file is *not* an EPS file, this
>> might succeed or fail.
>>
>> XeTeX/xdvipdfmx/dvipdfmx are using ghostscript with option `-dEPSCrop',
>> configured in TDS:dvipdfmx/dvipdfmx.cfg. This option *requires*
>> EPS files. It seems that ghostscript can be fooled by an EPSF header
>> line, e.g. %!PS-Adobe-2.0 EPSF-2.0
>>
>
> I have tested
> D "epstopdf --outfile='%o' '%i'"
> in dvipdfmx.cfg.
> It worked fine with the present xetex.def and dvipdfmx.def.
> This can be a good way, though it is too late for TL 2014.
> Note that repstopdf does not work since %o is an absolute
> path.
>
> Thanks,
> Akira
>
>
>
>
> --------------------------------------------------
> Subscriptions, Archive, and List information, etc.:
>  http://tug.org/mailman/listinfo/xetex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/xetex/attachments/20140529/7d98d1fb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pdf
Type: application/pdf
Size: 3719 bytes
Desc: not available
URL: <http://tug.org/pipermail/xetex/attachments/20140529/7d98d1fb/attachment.pdf>