[tex-live] mvorigin option in (x)dvipdfmx

[Zdenek Wagner]

These files are generated by a text editor. If the EPS files are converted
to PDF by epstopdf, everything is OK. LaTeX + dvips + ps2pdf does the right
thing. XeLaTeX without any options for xdvipdfmx cuts the part with the
negative coordinates, the origin is at the lower left corner.. LaTeX +
dvipdfmx moces the origin to the upper right corner so that the part with
the negative coordinates is shown but the part with the positive
coordinates is clipped.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2017-02-27 22:10 GMT+01:00 David Carlisle <d.p.carlisle at gmail.com>:

> On 27 February 2017 at 21:02, Akira Kakuto <kakuto at fuk.kindai.ac.jp>
> wrote:
> > Dear David,
> >
> >> If metapost generated EPS are included, the bounding box offsets are
> >> not propagated unless the mvorigin option is passed through to
> >> xdvipdfmx.
> >
> >
> > Please use the .mps suffix for MetaPost-generated eps 'without'
> --mvorigin
> > option.
> > MetaPost-generated eps:
> >   suffix .mps ---> should not use --mvorigin option
> >   otherwise  ---> should use --mvorigin option
> >
> > Best,
> > Akira
> >
> hi, yes I see that's the documented behaviour but I'm trying to
> understand the issue?
> Why make the user do either of those things? Can't I just detect the
> negative coordinates
> in xetex.def and shift the image in to place if the driver is going to
> mis-place it?
>
> If I get an eps file from somewhere why should I know it was generated
> by metapost
> and why should iIexpect that
>
> \fbox{includegraphics{file.eps}}
>
> fails to put the image in the box with xetex when it does with latex+dvips?
>
> What I can't tell looking at the code comments is if it is really an
> issue with metapost generated files
> (which I can not detect in xetex.def) or if it is an issue with any
> eps with negative coordinates in the bounding box
> (for which I could add translate in the tex macros if that is needed.
>
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20170227/4fbfdd87/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.eps
Type: application/postscript
Size: 129 bytes
Desc: not available
URL: <http://tug.org/pipermail/tex-live/attachments/20170227/4fbfdd87/attachment.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ab.tex
Type: application/x-tex
Size: 151 bytes
Desc: not available
URL: <http://tug.org/pipermail/tex-live/attachments/20170227/4fbfdd87/attachment.tex>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b.eps
Type: application/postscript
Size: 135 bytes
Desc: not available
URL: <http://tug.org/pipermail/tex-live/attachments/20170227/4fbfdd87/attachment-0001.eps>