[tex-live] Asymptote/DviPS and ghostscript (gone) epswrite device

[Dr. Werner Fink]

On Wed, Feb 04, 2015 at 11:54:10PM +0000, Karl Berry wrote:
> Werner,
> 
>       https://bugzilla.opensuse.org/show_bug.cgi?id=897284
>       https://bugzilla.opensuse.org/show_bug.cgi?id=912398
>       http://bugs.ghostscript.com/show_bug.cgi?id=695503
> 
> Well, it is not easy to digest those lengthy bug reports, full of
> diatribes by various people against other various people, but as far as
> I can make out, this is the standard problem of an eps file containing
> references to glyphs (typically in figure captions), but not embedding
> the fonts as needed.  For example, the diagram.eps in the 897284 has no
> fonts embedded.
> 
> Such eps files has been common in the TeX world for decades, no matter
> how much the ghostscript people might hate it, and I'm sorry they have
> eradicated one of the routes people used to get their work done.
> 
> If the above is right, I think the only robust fix is to generate eps
> files that do have the necessary fonts embedded.  For that, it seems the
> bug must go to Asymptote.  John and I can discuss if he agrees (and has
> any time to work on it).
> 
> For the moment, it should certainly be possible to pass the .eps through
> Ghostscript to get the fonts embedded, before running through dvips.
> I just did a bunch of experiments without conclusive results, due to
> Ghostscript optimizing and compressing the output, but what comes to
> mind is stuff like:
>   eps2eps -dEmbedAllFonts diagram.eps foo.eps
> or, more or less equivalently,
>   epstopdf --device=ps2write diagram.eps -o foo.eps
> 
> There are an awful lot of (e)ps-to-something tools out there.  Sorry, I
> don't have the energy to research and fight Ghostscript behavior down to
> the bitter end right now.
> 
> FWIW, this situation occurs with some regularity with TUGboat
> submissions.  Since what I want there is, ultimately, PDF, I run the
> "final" pdf generated by dvips|gs or pdftex or whatever through gs
> specifically to embed the fonts; works just as well with ps as input:
> gs \
>   -q -dNOPAUSE -dBATCH \
>   -dEmbedAllFonts -dPDFSETTINGS=/prepress -dAutoRotatePages=/None \
>   -sDEVICE=pdfwrite \
>   -sOutputFile=output_name.pdf -c .setpdfwrite \
>   -f input_name.pdf quit.ps
> 
> (This invocation is essentially copied from ps2pdfwr plus the embedding
> options, which I suppose I should just call ... anyway ...)
> 
> One last note: I believe there is a bug in dvips wrt font embedding,
> occurring when the same font is used in more than one figure file, each
> needing different glyphs, but used under the same (PostScript) name.
> (Unfortunately, I don't have a reference at hand.)  However, I don't get
> the feeling that's what's happening here.
> 
> Feel free to paste this note into your suse reports if you think it'd be
> helpful.

Just done and also tried your mentioned commands with the example in
bug boo#897284 but after

  mv hdr_KDK.eps hdr_KDK.eps.orig
  mv doc.ps doc.ps.orig
  mv doc.dvi doc.dvi.orig
  eps2eps -dEmbedAllFonts hdr_KDK.eps.orig  hdr_KDK.eps
  latex doc.tex
  latex doc.tex
  dvips doc.dvi

I see a blank page.  The graphic hdr_KDK.eps for its self looks OK.
After running

  ps2epsi hdr_KDK2.eps
  dvips doc.dvi

I see the same broken layout in the final PostScript file doc.ps that
is that glyps are missed.  I guess that as the font provided/included from
dvips will be used regardless if later the full font is loaded again.

Indeed after running

  dvips -j0 doc.dvi

the full graphic is visible regardless if I use the original eps or the
larger one. IMHO the default `j' in config.ps for dvips should become `j0'.


Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://tug.org/pipermail/tex-live/attachments/20150205/cdf77198/attachment.bin>