[tex-live] dvipdfmx and dvips(k): different special psfile output

Ramón Casares papa at ramoncasares.com
Wed Mar 2 11:33:26 CET 2016


Dear Akira,

> > But I am not sure that
> > files created by MetaPost are so peculiar.
> 
> No, they are not peculiar.
> (x)dvipdfmx can include eps created by MetaPost without
> help of other applications such as Ghostscript.
> However other eps files must be changed to epdf by
> Ghostscript. The created epdf, in the present dvipdfmx.cfg,
> have llx = lly = 0, so we need 'peculiar' handling in
> dvipdfmx.def/xetex.def. Therefore when we use
> dvipdfmx.def/xetex.def, we need 'peculiar' moving of the
> origin for MetaPost-created eps files, since they are
> not converted into epdf files.

Thank you for your patience with me.

I am now beginning to understand what is going on.
Let me please repeat what you are saying with my own words,
just to confirm that I am understanding you rightly.

The problem is caused by a limitation of Ghostscript
   http://ghostscript.com/doc/9.16/Issues.htm
related to bug 202735
   http://bugs.ghostscript.com/show_bug.cgi?id=202735
where I read that
"This is an architectural restriction in Ghostscript:
all devices impose an implicit clipping region
of [0 0 infinity infinity] in device space".

The solution is to translate the image
to the first quadrant coordinates using -dEPSCrop
when doing the Ghostscript conversion to pdf,
and then undo the translation.

Now, the peculiarity of Metapost generated figures
is that they use a known subset of Postscript operations
and then they can be converted to pdf without the
help of Ghostscript. In these cases the
final undo movement must be omitted.

I am very sorry for wasting your time,
but until I have learned of that limitation of Ghostscript,
I was doing the wrong deductions.
Thank you very much for your time,
and for your good work with dvipdfmx.
   Ramón Casares


More information about the tex-live mailing list