Bug 897284 - LaTeX: dvips embedds "StandardSymL" font with only a subset of the glyphs of the standard "Symbol" font
LaTeX: dvips embedds "StandardSymL" font with only a subset of the glyphs of ...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE 13.1
Classification: openSUSE
Component: Other
Final
All openSUSE 13.1
: P4 - Low : Minor (vote)
: ---
Assigned To: Dr. Werner Fink
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-18 10:33 UTC by Ulrich Deiters
Modified: 2015-07-15 16:37 UTC (History)
5 users (show)

See Also:
Found By: Community User
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
werner: needinfo? (ulrich.deiters)


Attachments
ZIP archive containing the latex file, the EPS diagram, and the generated PostScript file (13.25 KB, application/zip)
2014-09-18 10:33 UTC, Ulrich Deiters
Details
test document 2 (ZIP archive containing LaTeX and EPS file) (25.71 KB, application/zip)
2014-09-19 12:57 UTC, Ulrich Deiters
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Deiters 2014-09-18 10:33:52 UTC
Created attachment 606818 [details]
ZIP archive containing the latex file, the EPS diagram, and the generated PostScript file

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0

I am using the standard TeXLive installation that comes with openSUSE. My diagrams are encapsulated PostScript (EPS); I load them into the LaTeX document with the \epsfig command (package epsfig, for embedded diagrams) or \special (for background graphics).

When I use the \Pisymbol command (package pifont) to print a character from the Symbol font, symbols from this font in the diagram are suppressed.

There are no error messages from the latex nor from the dvips command. The DVI file looks correct.

When I delete the \Pisymbol invocation, or let it use another font, the diagram is rendered correctly.

Reproducible: Always

Steps to Reproduce:
1. unzip doc.zip
2. latex doc
3. dvips -o docnew.ps doc
4. okular docnew.ps (or any other PostScript viewer)
Actual Results:  
The generated PS file shows a part of an axis lable at its bottom, "vap H m/(RT)",
with "m" and "vap" as subscripts.

Expected Results:  
The label should be "Delta vap H m/(RT)", with a Greek Delta character.

The problem is not limited to the pifont package.

The problem did not exist on my computer two or three years ago. It may have something to do with the adoption of the TeXLive system.
Comment 1 Bernhard Wiedemann 2014-09-18 14:01:11 UTC
I could reproduce it with the steps above after
zypper -n in --recommends texlive

also xdvi doc.dvi
shows the delta symbol, whereas   gv docnew.ps
does not
Comment 2 Dr. Werner Fink 2014-09-18 14:14:18 UTC
True, but I do not have the time to fix this. Try using

       pdflatex doc.tex

and then use any pdf viewer.
Comment 3 Dr. Werner Fink 2014-09-18 14:18:10 UTC
Could be a font problem in ghostscript used by gv and any other PS viewer

/tmp/tex> gs doc.ps
GPL Ghostscript 9.07 (2013-02-14)
Copyright (C) 2012 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusRomNo9L-Regu font from /usr/share/ghostscript/9.07/Resource/Font/NimbusRomNo9L-Regu... 3419856 1960778 6832008 5330061 3 done.
Loading NimbusRomNo9L-ReguItal font from /usr/share/ghostscript/9.07/Resource/Font/NimbusRomNo9L-ReguItal... 3419856 2017133 6832008 5338169 3 done.
>>showpage, press <return> to continue<<
Comment 4 Ulrich Deiters 2014-09-18 15:15:17 UTC
Using pdflatex instead of latex works. So there is a good workaround.

Sending the doc.ps file generated by dvips directly to a PostScript printer gives a correct printout. This might indeed point to a bug in ghostscript.
Comment 5 Johannes Meixner 2014-09-19 07:33:36 UTC
Ulrich Deiters,
I did not yet do any analysis regarding Ghostscript but
when you are an experienced user, I recommend that
you try out the newest Ghostscript that is available
(currently Ghostscript version 9.15 release candidate 2).

The newest packages for the base printing system are available
for various openSUSE and SUSE Linux Enterprise versions
in the "Printing" development project in the openSUSE build service
for 32-bit i586 and 64-bit x86_64 architecture.
For example for openSUSE 13.1 from this direct URL
http://download.opensuse.org/repositories/Printing/openSUSE_13.1/
(some packages like OpenPrintingPPDs are in the "noarch" subdirectory).

Please read
https://build.opensuse.org/project/show?project=Printing
in particular note therein:
=========================================================
The "Printing" project may contain new, upcoming
software. Therefore the packages in the "Printing"
project might neither be in a stable state nor fit
well into currently installed systems.
Have this in mind if you think about to install
packages from the "Printing" project into your
currently running system.
Do not use "Factory" if your system is
not "Factory". Use the matching packages
for your particular system.
The packages in the "Printing" project are
only for testing, without any guarantee
or warranty, and without any support.
As an extreme example, this means if your
complete computer center crashes because
of those packages, it is only your problem.
On the other hand this does not mean that those
packages are known to be terrible broken but
they are not thoroughly tested so that any
unexpected issue can happen.
=========================================================

I assume you are a venturous openSUSE user who likes to try out
if new packages from the "Printing" project work for you.
In this case please report whether or not it works for you.

Many thanks in advance for testing it and for your feedback!
Comment 6 Dr. Werner Fink 2014-09-19 07:48:48 UTC
(In reply to comment #5)

I guess that the font is simply missing the delta symbol or the mapping for the delta symbol. For the last case the font could be patched as we had done this in past for ghostscript-fonts by using

  for pfa in $list
  do
      t1ascii  ${pfa%%.*}.pfb > ${pfa}
  done
  patch -p0 -i %{P:24}
  for pfa in $list
  do
      t1binary ${pfa} > ${pfa%%.*}.pfb
      rm -vf ${pfa}
  done
Comment 7 Johannes Meixner 2014-09-19 09:11:27 UTC
Upgrading Ghostscript cannot help when the root cause is in a font.
I have basically no knowledge at all about fonts.

Note that ghostscript-fonts-std and ghostscript-fonts-other
are no Ghostscript sub-packages but separated packages
(they are sub-packages of the ghostscript-fonts package).

If I remember correctly there have been some changes/updates
regarding Ghostscript's free fonts but I did not have the time
to work on it and investigate what the current actual state is.

E.g. /usr/share/doc/packages/ghostscript/Fonts.htm still shows the
no longer working URL ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/fonts/
but it seems meanwhile Ghostscript's free fonts are under
http://downloads.ghostscript.com/public/fonts/

Ulrich Deiters,
when the root cause is in Ghostscript's fonts, you may try out
if it works with Ghostscript's free fonts from
http://downloads.ghostscript.com/public/fonts/
Comment 8 Johannes Meixner 2014-09-19 09:12:59 UTC
I assume the issue happens on all architectures.
Comment 9 Johannes Meixner 2014-09-19 09:23:01 UTC
Regarding the outdated Fonts.htm documentation
I submitted the upstream bug report
http://bugs.ghostscript.com/show_bug.cgi?id=695499
Comment 10 Johannes Meixner 2014-09-19 09:35:25 UTC
Regarding comment#6 "the font could be patched"
see ghostscript-fonts.spec 
https://build.opensuse.org/package/view_file/Printing/ghostscript-fonts/ghostscript-fonts.spec?expand=1
----------------------------------------------------------------------------
# Source100 ghostscript-fonts-std-8.11.patch is made by mfabian@suse.de
# see https://bugzilla.novell.com/show_bug.cgi?id=suse36778 (bnc#51778).
# It changes the weight of "Nimbus Roman No9 L:style=Medium Italic" and
# "Nimbus Roman No9 L:style=Medium" back to "Bold" instead of "Medium".
# ghostscript-fonts-std-8.11.patch must be listed as SourceNNN
# because it is applied via an explicit patch call in install section
# but the SUSE internal check_if_valid_source_dir tool could abort
# with fatal error because it thinks this patch is not applied
# (see https://bugzilla.novell.com/show_bug.cgi?id=649207#c17):
Source100:      ghostscript-fonts-std-8.11.patch
...
# Patch the installed ghostscript-fonts-std fonts:
PATCH_FILE=$RPM_SOURCE_DIR/ghostscript-fonts-std-8.11.patch
PFA_FILES="$( grep -o '^+++ .*\.pfa' $PATCH_FILE | cut -s -d ' ' -f2 )"
pushd %{buildroot}%{_datadir}/ghostscript/fonts
for PFA in $PFA_FILES
do t1ascii ${PFA%%.*}.pfb >$PFA
done
patch -p0 -i $PATCH_FILE
for PFA in $PFA_FILES
do t1binary $PFA > ${PFA%%.*}.pfb
   rm -vf $PFA
done
popd
----------------------------------------------------------------------------

I.e. ghostscript-fonts-std-8.11.patch is still applied but I don't think
this patch has something to do with the delta symbol and I am unable
to patch fonts.
Comment 11 Ulrich Deiters 2014-09-19 12:57:48 UTC
Created attachment 607022 [details]
test document 2 (ZIP archive containing LaTeX and EPS file)

test case #2: font collision when a LaTeX document is printed onto a background graphic.
Comment 12 Ulrich Deiters 2014-09-19 13:01:27 UTC
I am not sure that the Symbol font is to blame or needs to be patched. The weird behaviour occurs frequently when LaTeX uses a font that is also used by
the EPS diagram.

I attach another LaTeX document, in which a text is printed over an EPS graphic. I used the letterhead of our kendo club for this, but removed the
fancy logo and some other superfluous details.

When you view the EPS file with okular or whatever, you will see a blue "Kendo Dojo Köln e.V." line.

When you run latex and dvips on the LaTeX file and view the result, the line becomes "… e … e …"; if you print the result on a PostScript printer, the line is printed OK. Therefore I suppose that doc.ps is correct, and that latex and dvips are working correctly, but my PostScript viewer does not.

Using pdflatex is not a good idea: it does not load the EPS graphic.

The problem occurs because *both* the background graphic and the text use the Helvetica-Bold font. As soon as I switch to Helvetica-BoldItalic in *one* location, the problem is gone. I think this points to a bug in ghostview, not in the fonts.

P.S.: I am an adventurous user, but also a busy one. I may have to postpone testing the latest ghostview version to the end of next week.
Comment 13 Johannes Meixner 2014-09-19 14:31:56 UTC
Ghostscript upgrade seems not to help.

For your attachment#606818 [details]
when I use Ghostscript 9.15 rc2
then
"gs -r75 diagram.eps"
shows "DELTAvapHm/(RT)", with a Greek DELTA character
and "m" and "vap" as subscripts.
but
"gs -r75 doc.ps"
shows "vapHm/(RT)", without the Greek DELTA character
and "m" and "vap" as subscripts.

There is a difference what fonts Ghostscript loads:
----------------------------------------------------------------------------
$ gs -r75 diagram.eps
GPL Ghostscript RELEASE CANDIDATE 2 9.15 (2014-03-25)
...
Loading NimbusRomNo9L-Regu font from /usr/share/ghostscript/9.15/Resource/Font/NimbusRomNo9L-Regu... 3822044 2318928 2856384 1561572 2 done.
Loading StandardSymL font from /usr/share/ghostscript/9.15/Resource/Font/StandardSymL... 3838764 2380759 2856384 1564720 2 done.
Loading NimbusRomNo9L-ReguItal font from /usr/share/ghostscript/9.15/Resource/Font/NimbusRomNo9L-ReguItal... 3855484 2451595 2876484 1571564 2 done.
>>showpage, press <return> to continue<<
----------------------------------------------------------------------------
versus
----------------------------------------------------------------------------
$ gs -r75 doc.ps  
GPL Ghostscript RELEASE CANDIDATE 2 9.15 (2014-03-25)
...
Loading NimbusRomNo9L-Regu font from /usr/share/ghostscript/9.15/Resource/Font/NimbusRomNo9L-Regu... 3822044 2398988 5097064 3736455 3 done.
Loading NimbusRomNo9L-ReguItal font from /usr/share/ghostscript/9.15/Resource/Font/NimbusRomNo9L-ReguItal... 3838764 2469906 5097064 3744767 3 done.
>>showpage, press <return> to continue<<
----------------------------------------------------------------------------

I.e. for doc.ps Ghostscript does no longer load the StandardSymL font
regardless that there is "/Symbol findfont 16 scalefont setfont"
both in diagram.eps and in doc.ps.
Comment 14 Dr. Werner Fink 2014-09-19 14:44:20 UTC
(In reply to comment #12)

> Using pdflatex is not a good idea: it does not load the EPS graphic.

Maybe you may install texlive-epstopdf ... from the description

  Epstopdf is a Perl script that converts an EPS file to an
  'encapsulated' PDF file (a single page file whose media box is
  the same as the original EPS's bounding box). The resulting
  file suitable for inclusion by PDFTeX as an image. The script
  is adapted to run both on Windows and on Unix-alike systems.
  The script makes use of Ghostscript for the actual conversion
  to PDF. It assumes Ghostscript version 6.51 or later, and (by
  default) suppresses its automatic rotation of pages where most
  of the text is not horizontal. LaTeX users may make use of the
  epstopdf package, which will run the epstopdf script "on the
  fly", thus giving the illusion that PDFLaTeX is accepting EPS
  graphic files.
Comment 15 Johannes Meixner 2014-09-22 08:28:38 UTC
The reason why Ghostscript does not load the StandardSymL font
in case of doc.ps is that doc.ps conains this font:
--------------------------------------------------------------------------
%!PS-Adobe-2.0
%%Creator: dvips(k) 5.993 Copyright 2013 Radical Eye Software
...
%%BeginFont: StandardSymL
%!PS-AdobeFont-1.0: StandardSymL 001.005
%%CreationDate: Thu Oct 21 1999
...
/FontName /StandardSymL def
...
%%EndFont
--------------------------------------------------------------------------

It seems that dvips includs that font into its PostScript but
with this font it does not work to show a Greek DELTA character.

When I remove this font from doc.ps (i.e. the above mentioned lines
from "%%BeginFont: StandardSymL" up to the next "%%EndFont"),
then "gs -r75 doc.ps" loads the StandardSymL font
from /usr/share/ghostscript/9.15/Resource/Font/StandardSymL
and with that font, it works to show a Greek DELTA character.

Summary (according to my current analysis):

dvips includes a font named "StandardSymL" that does not work for
Ghostscript to show a Greek DELTA character.

Accordingly I re-assign the issue back to the maintainer
of TeX and LaTeX for further analysis.

Nevertheless there could be still an issue in Ghostscript because:

Also on my HP LaserJet 1200 PostScript printer the Greek DELTA character
is printed when I send doc.ps directly (in "raw" mode) to the printer
(cf. comment#4 above) via "lp -d <queue_name> -o raw doc.ps"

I.e. my printer's built-in PostScript interpreter can print a Greek
DELTA character with the StandardSymL font that is included in doc.ps
but Ghostscript cannot which may indicate an issue in Ghostscript
with the StandardSymL font that is included by dvips in doc.ps.

FYI:

My HP LaserJet 1200 PostScript printer also prints a Greek DELTA character
after I have removed the included StandardSymL font from doc.ps
when I send the remaining PostScript in "raw" mode to the printer.
Comment 16 Johannes Meixner 2014-09-22 08:31:48 UTC
It seems after Bugzilla upgrade I can no longer re-assign it to Werner.
Therefore I reset the assignee to default.
Comment 17 Johannes Meixner 2014-09-22 09:16:30 UTC
FYI:

I found out why I was no longer allowed to re-assign it to Werner.

I had used my now outdated browser bookmark that points to
bugzilla.novell.com and there I am no longer allowed to re-assign.

Now I use bugzilla.suse.com and/or bugzilla.opensuse.org
where I am allowed to re-assign.

This means:

Make sure to use the right bugzilla URL:

for openSUSE use bugzilla.opensuse.org

for SUSE use bugzilla.suse.com

see the Bugzilla3x-to-4x-UpgradeTransition.pdf
Comment 18 Johannes Meixner 2014-09-23 07:38:50 UTC
I think
http://bugs.ghostscript.com/show_bug.cgi?id=695506
could be basically the same issue and
http://bugs.ghostscript.com/show_bug.cgi?id=694537#c2
could be background information also for this issue here
regardless that this issue here is about PostScript and not PDF
but I think in the end the font issue is the same in both cases
(subject to the fact that I am not at all a font expert).

I think in this case here the "multiple files containing fonts
with the same name" are
- the PostScript that is generated from the LaTeX source file
- the encapsulated PostScript file that is addeed
and both use a font named "StandardSymL".

Nevertheless I do not understand why PostScript printers
do print the Greek DELTA character.
Comment 19 Johannes Meixner 2014-09-23 08:05:29 UTC
I submitted an issue report at Ghostsript upstream:
http://bugs.ghostscript.com/show_bug.cgi?id=695508
Comment 20 Johannes Meixner 2014-09-23 10:59:25 UTC
I think
http://bugs.ghostscript.com/show_bug.cgi?id=695508#c3
explains it perfectly.

Excerpt:
--------------------------------------------------------------------------
...

In doc.ps, the Postscript file embeds a font called "StandardSymL" before
the EPS is included. Thus when the EPS requests "Symbol", which gets
mapped to "StandardSymL" there is already a font called "StandardSymL"
in memory, which (as per the PS spec) we then use. Unfortunately, that
embedded "StandardSymL" is a subset, which does not contain /Delta, and
hence a non-marking "/.notdef" glyph is drawn instead.

Whether a given interpreter prints the /Delta or not really depends on
whether they include a "real" "Symbol" font, or if not, what it's
substitute is called - knowing HP printers, my guess is the HP has
a font whose "real" name is Symbol, hence it doesn't try to use the
already defined "StandardSymL".

...

the app that emitted the PS file (apparently dvips) use a subset prefix
on the font name when embedding (that prefixes the font name with a six
letter (and "+") randomly generated sequence - for example, our own
ps2write device uses a hashing algorithm to produce a subset prefixed
name of "/EFSMOM+StandardSymL" for the embedded version of StandardSymL.
It would be worth raising that anyway, as it's bad practice not to.

Finally, the bestest solution is to have the creator of the EPS
(Grafix-3.0) embed the fonts it's using. Although strictly speaking
it is not required to embed the "core" PS fonts, it does guarantee
consistent results, and avoids problems like this one occurring.
--------------------------------------------------------------------------

From my point of view the real bug is in dvips because it embedds
a font called "StandardSymL" that only provides a subset of the
gylphs in the "Symbol" font of the PostScript Core Font Set, see
http://en.wikipedia.org/wiki/PostScript_fonts#Core_Font_Set
Comment 21 Johannes Meixner 2014-10-02 10:20:45 UTC
Perhaps I found a possible workaround to avoid the font mess:

The basic idea behind is to make the EPS so that it does no longer
need any font (also not any standard PostScript font).

Ghostscript can be used to re-create a PostScript or EPS file from scratch
in such a way which means all text will be drawn by emitting the glyph
description directly into the page stream every time a glyph is used.
For most fonts this will result in paths, for bitmap fonts it will result
in bitmaps. Note that the output will be larger, slower to process, the
text rendering will be less consistent and, particularly at lower
resolution, of poorer quality. See the somewhat related mail thread
about "pswrite and NOPLATFONTS" on the gs-devel@ghostscript.com
mailing list - but I am really not an expert in this area
so that I could misunderstand something.

I use Ghostscript version 9.15 (from the openSUSE build service
development project "Printing") and for me it worked by using the
epswrite device without any parameters:

# gs -sDEVICE=epswrite -dBATCH -dNOPAUSE \
 -sOutputFile=diagram.epswrite.eps diagram.eps

When I exchange in doc.ps the included diagram.eps
by my new diagram.epswrite.eps and save the result
in doc.with_diagram.epswrite_eps.ps then

# gs -r75 doc.with_diagram.epswrite_eps.ps

shows the Greek DELTA character.


Ulrich Deiters,
perhaps you can make your EPS files in a similar way
to avoid any kind of font mess.

Note that depending on the Ghostscript version it may vary
if -sDEVICE=epswrite and/or -sDEVICE=eps2write produce output
that does no longer need any font - you may have to use further
parameters to enforce that kind of output.

Ulrich Deiters,
could you try it out and provide feedback whether or not it
is a usable workaround for you?
Comment 22 Johannes Meixner 2014-10-02 10:27:19 UTC
FYI:

To verify whether or not a PostScript or EPS file needs any font,
use Ghostscript and watch its output about "Loading ... font".

For example in my case:
--------------------------------------------------------------------------
$ gs -sDEVICE=nullpage -dBATCH -dNOPAUSE diagram.eps \
  | grep -o '^Loading .* font'

Loading NimbusRomNo9L-Regu font
Loading StandardSymL font
Loading NimbusRomNo9L-ReguItal font

$ gs -sDEVICE=nullpage -dBATCH -dNOPAUSE diagram.epswrite.eps \
  | grep -o '^Loading .* font'
[no output]
--------------------------------------------------------------------------
Comment 23 Ulrich Deiters 2014-10-04 14:57:23 UTC
I just tested your suggestion: It works!

The problem points to a failure of the encapsulation or a conflict within the font management, hence it should be fixed in GhostScript at some future time. But thanks to your workaround it is no longer pressing.

Thank you!
Comment 24 Johannes Meixner 2014-10-06 07:33:47 UTC
See what a Ghostscript upstream author explained in
http://bugs.ghostscript.com/show_bug.cgi?id=695508#c3
------------------------------------------------------------------------
Even though it isn't a bug in gs, I'd be willing the look at solutions,
but the reality is there is simply no way to resolve this issue,
in the general case, in a Postscript interpreter (any resolution
would either allow the same issue with different font names,
or would simply break Postscript rules).
------------------------------------------------------------------------
Because it is no bug in Ghostscript, there is nothing to be fixed there
and the above does not look as if such issues can be avoided at all.

As far as I understand it, the real bug is that an application (dvips)
embedds only a subset of a font but did not use an application specific
font name for its application specific font subset, see
http://bugs.ghostscript.com/show_bug.cgi?id=695508#c3
------------------------------------------------------------------------
... request that the app that emitted the PS file (apparently dvips)
use a subset prefix on the font name when embedding (that prefixes the
font name with a six letter (and "+") randomly generated sequence - for
example, our own ps2write device uses a hashing algorithm to produce
a subset prefixed name of "/EFSMOM+StandardSymL" for the embedded
version of StandardSymL. It would be worth raising that anyway,
as it's bad practice not to.
------------------------------------------------------------------------

In other words:
dvips makes PostScript that states it contains a (whole) font
but actually it contains only a subset of the font's glyphs.
Comment 25 Johannes Meixner 2014-10-06 09:23:11 UTC
Only FYI:

I wonder if one can enforce dvips to embedd whole fonts
instead of only subsets of fonts.

It is ages ago since I used LaTeX so that all I did was
to "google" for dvips man pages and dvips font stuff:

At
https://www.ma.utexas.edu/cgi-bin/man-cgi?dvips+1
I found an outdated dvips man page that reads:
-----------------------------------------------------------------------------
THIS MAN PAGE IS OBSOLETE!
...
-j     Download only needed characters from Type 1 fonts.
       This is the default in the current release.
-----------------------------------------------------------------------------

At
http://www.tug.org/tetex/html/dvips/dvips_18.html
I think there is a more up-to-date dvips man page but it seems
meanwhile the '-j' option does no longer exist.

At
http://tug.org/pipermail/tex-live/2012-November/032650.html
it seems a similar issue is described plus using "dvips -j0".
Comment 26 Dr. Werner Fink 2015-02-05 09:23:30 UTC
The message <201502042354.t14NsAZk021019@freefriends.org> from Karl Berry <karl@freefriends.org>

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.

Best,
Karl
Comment 27 Dr. Werner Fink 2015-02-05 09:27:44 UTC
Indeed it is a feature of dvips to include only those glyphs which are definitely used in the PostScript text.  Therefore I'd like to know if the commands below Karl has mentioned in his mail and I've cited in comment #26.

These commands are

  eps2eps -dEmbedAllFonts diagram.eps foo.eps

or

  epstopdf --device=ps2write diagram.eps -o foo.eps

does this help you to generate eps files which are useable with dvips?
Comment 28 Johannes Meixner 2015-02-05 09:52:13 UTC
Regarding comment#26 where Karl Berry wrote:

"the only robust fix is to generate eps files
 that do have the necessary fonts embedded"

I do not agree.

Reasoning (as far as I understand it and regardless that I am
not at all a font expert):

Assume inner.eps has its needed font "SomeFont" included.

Assume outer.ps also needs the font "SomeFont" but has
only a subset of that font included.

According to what Chris Liddell explained in
http://bugs.ghostscript.com/show_bug.cgi?id=695508#c3
------------------------------------------------------------------------
there is already a font called "..." in memory, which
(as per the PS spec) we then use
------------------------------------------------------------------------
when inner.eps gets included in outer.ps to make a document.ps
then the subset of the font called "SomeFont" from outer.ps
is also used "(as per the PS spec)" for inner.eps.

Conclusion:
It does not change anything when inner.eps has its needed font
included if outer.ps has only a subset of the same font included.

Therefore (as far as I understand it and regardless that I am
not at all a font expert) the only robust solution is when
an application that includes only a subset of a font,
then that application must use its own application-specific
artificial name for its own application-specific subset-font.

In the above inner.eps / outer.ps example the solution would be:

Assume inner.eps has its needed font "SomeFont" (completely) included.

Assume outer.ps also needs the font "SomeFont" but has
only a subset of that font included and therefore it has
its particular subset included under the name "MySubsetOfSomeFont".

Then a PostScript interpreter would incude both fonts:
"MySubsetOfSomeFont" and "SomeFont" and everything could "just work".

See what Chris Liddell explained in
http://bugs.ghostscript.com/show_bug.cgi?id=695508#c3
------------------------------------------------------------------------
request that the app that emitted the PS file (apparently dvips)
use a subset prefix on the font name when embedding (that prefixes
the font name with a six letter (and "+") randomly generated
sequence - for example, our own ps2write device uses a hashing
algorithm to produce a subset prefixed name of "/EFSMOM+StandardSymL"
for the embedded version of StandardSymL. It would be worth raising
that anyway, as it's bad practice not to.
------------------------------------------------------------------------
Comment 29 Johannes Meixner 2015-02-05 09:56:53 UTC
Werner,

as far as I understand it the issue is not the feature of dvips
to include only those glyphs which are used in the PostScript.

The issue is that dvips includes only those glyphs which are
used under the same name as the complete font.

In short:
When dvips includes a font called "SomeFont" it lies about
that this is not the real "SomeFont" but only a subset of it.
Comment 30 Johannes Meixner 2015-02-05 10:07:44 UTC
FWIW:

As far as I understand in comment#26 what Karl Berry wrote:
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------

This one is exactly the same bug.

It seems dvips can make PostScript which looks like this:

1.
include subset1-of-font-SomeFont named "SomeFont"

2.
use "SomeFont"

3.
print glyphs from subset1-of-font-SomeFont

4.
include subset2-of-font-SomeFont named "SomeFont"

5.
use "SomeFont"

6.
print glyphs from subset2-of-font-SomeFont

At step 4. a PostScript interpreter would not re-include "SomeFont"
because a font with this name is already in memeory (via step 1.).

Therefore at step 6. it fails to print glyphs from subset2-of-font-SomeFont
that are not already included in subset1-of-font-SomeFont.


The solution would be:

1.
include subset1-of-font-SomeFont named "Subset1SomeFont"

2.
use "Subset1SomeFont"

3.
print glyphs from subset1-of-font-SomeFont

4.
include subset2-of-font-SomeFont named "Subset2SomeFont"

5.
use "Subset2SomeFont"

6.
print glyphs from subset2-of-font-SomeFont
Comment 32 Dr. Werner Fink 2015-02-05 10:32:47 UTC
@Ulrich:

  Please try out

    sudo sed -ri '/^j/{ s/j.*/j0/ }' /etc/texmf/dvips/config/config.ps

  and redo the dvips on your documents
Comment 35 Ulrich Deiters 2015-02-05 23:07:14 UTC
The fonts I was using are "standard fonts", which should be known to each PostScript interpreter. Hence there should not be any need to embed them. If glyphs are missing in the final document, this might indicate that something is wrong with the way how dvips handles encapsulations, or that the font dictionary gets messed up. But I am not an expert for the innards of PostScript interpreters.

I made some tests as required:

(1) I ran the EPS file through eps2eps -dEmbedAllFonts ...,
    mentioned the transformed EPS file in the LaTeX source file,
    and then invoked "latex" and "dvips": The result was a white page.

(2) I mentioned the original EPS file in the LaTeX source file,
    ran "latex" and "dvips", then used
    gs ... -dEmbedAllFonts -sDEVICE=pdfwrite ...
    
    With the option "-c .setpdfwrite", I got an error message.
    Without the option, the missing glyphs problem persisted.

(3) I did the "sed -ri ..." to config.ps, and the problem disappeared!

Thanks for all your efforts!
Comment 36 Dr. Werner Fink 2015-04-01 07:58:51 UTC
The TeXLive 2014 will have j0 as default
Comment 37 Bernhard Wiedemann 2015-04-01 12:00:13 UTC
This is an autogenerated message for OBS integration:
This bug (897284) was mentioned in
https://build.opensuse.org/request/show/293921 Factory / texlive-specs-a
Comment 38 Bernhard Wiedemann 2015-04-01 13:00:11 UTC
This is an autogenerated message for OBS integration:
This bug (897284) was mentioned in
https://build.opensuse.org/request/show/293928 Factory / texlive-specs-h
https://build.opensuse.org/request/show/293949 Factory / texlive-specs-a
https://build.opensuse.org/request/show/293950 Factory / texlive-specs-b
https://build.opensuse.org/request/show/293951 Factory / texlive-specs-c
https://build.opensuse.org/request/show/293952 Factory / texlive-specs-d
https://build.opensuse.org/request/show/293953 Factory / texlive-specs-e
https://build.opensuse.org/request/show/293954 Factory / texlive-specs-f
https://build.opensuse.org/request/show/293955 Factory / texlive-specs-g
https://build.opensuse.org/request/show/293956 Factory / texlive-specs-i
https://build.opensuse.org/request/show/293957 Factory / texlive-specs-j
https://build.opensuse.org/request/show/293958 Factory / texlive-specs-k
https://build.opensuse.org/request/show/293959 Factory / texlive-specs-l
https://build.opensuse.org/request/show/293962 Factory / texlive-specs-n
https://build.opensuse.org/request/show/293963 Factory / texlive-specs-o
https://build.opensuse.org/request/show/293964 Factory / texlive-specs-p
https://build.opensuse.org/request/show/293965 Factory / texlive-specs-q
https://build.opensuse.org/request/show/293966 Factory / texlive-specs-r
https://build.opensuse.org/request/show/293967 Factory / texlive-specs-s
https://build.opensuse.org/request/show/293969 Factory / texlive-specs-t
https://build.opensuse.org/request/show/293970 Factory / texlive-specs-u
https://build.opensuse.org/request/show/293972 Factory / texlive-specs-v
https://build.opensuse.org/request/show/293973 Factory / texlive-specs-w
https://build.opensuse.org/request/show/293974 Factory / texlive-specs-x
https://build.opensuse.org/request/show/293975 Factory / texlive-specs-y
https://build.opensuse.org/request/show/293976 Factory / texlive-specs-z
Comment 39 Bernhard Wiedemann 2015-04-01 14:00:11 UTC
This is an autogenerated message for OBS integration:
This bug (897284) was mentioned in
https://build.opensuse.org/request/show/293990 Factory / texlive-specs-l
https://build.opensuse.org/request/show/293991 Factory / texlive-specs-m
Comment 40 Bernhard Wiedemann 2015-04-01 18:00:12 UTC
This is an autogenerated message for OBS integration:
This bug (897284) was mentioned in
https://build.opensuse.org/request/show/294024 Factory / texlive-specs-a
https://build.opensuse.org/request/show/294025 Factory / texlive-specs-b
https://build.opensuse.org/request/show/294026 Factory / texlive-specs-c
https://build.opensuse.org/request/show/294027 Factory / texlive-specs-d
https://build.opensuse.org/request/show/294028 Factory / texlive-specs-e
https://build.opensuse.org/request/show/294046 Factory / texlive-specs-f
https://build.opensuse.org/request/show/294047 Factory / texlive-specs-g
https://build.opensuse.org/request/show/294048 Factory / texlive-specs-h
https://build.opensuse.org/request/show/294049 Factory / texlive-specs-i
https://build.opensuse.org/request/show/294050 Factory / texlive-specs-j
https://build.opensuse.org/request/show/294051 Factory / texlive-specs-k
https://build.opensuse.org/request/show/294052 Factory / texlive-specs-l
https://build.opensuse.org/request/show/294053 Factory / texlive-specs-m
https://build.opensuse.org/request/show/294054 Factory / texlive-specs-n
https://build.opensuse.org/request/show/294055 Factory / texlive-specs-o
https://build.opensuse.org/request/show/294056 Factory / texlive-specs-p
https://build.opensuse.org/request/show/294057 Factory / texlive-specs-q
https://build.opensuse.org/request/show/294058 Factory / texlive-specs-r
https://build.opensuse.org/request/show/294059 Factory / texlive-specs-s
https://build.opensuse.org/request/show/294060 Factory / texlive-specs-t
https://build.opensuse.org/request/show/294061 Factory / texlive-specs-u
https://build.opensuse.org/request/show/294062 Factory / texlive-specs-v
https://build.opensuse.org/request/show/294063 Factory / texlive-specs-w
https://build.opensuse.org/request/show/294064 Factory / texlive-specs-x
https://build.opensuse.org/request/show/294065 Factory / texlive-specs-y
https://build.opensuse.org/request/show/294066 Factory / texlive-specs-z
Comment 41 Bernhard Wiedemann 2015-04-16 10:00:17 UTC
This is an autogenerated message for OBS integration:
This bug (897284) was mentioned in
https://build.opensuse.org/request/show/297150 Factory / texlive-specs-t
Comment 42 Ulrich Deiters 2015-07-15 16:37:52 UTC
The bug is back!

One of the recent updates re-installed it. I fixed the problem again by modifying /etc/texmf/dvips/config/config.ps, but it would be better to have correct updates.