<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 10:45 AM, Akira Kakuto <span dir="ltr"><<a href="mailto:kakuto@fuk.kindai.ac.jp" target="_blank">kakuto@fuk.kindai.ac.jp</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Heiko,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
`epstopdf' does not require that the PostScript file is a strict<br>
Encapsulated PostScript file. It takes the BoundingBox it can find,<br>
moves the graphics to the origin, sets the new media size<br>
(setpagedevice) and calls ghostscript for the conversion to PDF.<br>
In the case that the PostScript file is *not* an EPS file, this<br>
might succeed or fail.<br>
<br>
XeTeX/xdvipdfmx/dvipdfmx are using ghostscript with option `-dEPSCrop',<br>
configured in TDS:dvipdfmx/dvipdfmx.cfg. This option *requires*<br>
EPS files. It seems that ghostscript can be fooled by an EPSF header<br>
line, e.g. %!PS-Adobe-2.0 EPSF-2.0<br>
</blockquote>
<br>
I have tested<br>
D "epstopdf --outfile='%o' '%i'"<br>
in dvipdfmx.cfg.<br>
It worked fine with the present xetex.def and dvipdfmx.def.<br>
This can be a good way, though it is too late for TL 2014.<br>
Note that repstopdf does not work since %o is an absolute<br>
path.<br>
<br>
Thanks,<br>
Akira<br>
<br>
<br>
<br>
<br>
------------------------------<u></u>--------------------<br>
Subscriptions, Archive, and List information, etc.:<br>
 <a href="http://tug.org/mailman/listinfo/xetex" target="_blank">http://tug.org/mailman/<u></u>listinfo/xetex</a><br>
</blockquote></div><br></div>