We (SUSE) got this issue report from a user: https://bugzilla.opensuse.org/show_bug.cgi?id=897284 A PostScript file doc.ps was produced by LaTeX dvips program and it includes an encapsulated PostScript file diagram.eps. When diagram.eps is displayed via "gs -r75 diagram.eps" (default output device is x11alpha) Ghostscript is "Loading StandardSymL font from /usr/share/ghostscript/9.15/Resource/Font/StandardSymL" and a Greek DELTA character is shown. When doc.ps is displayed via "gs -r75 doc.ps" Ghostscript does not load a StandardSymL font because doc.ps has a font named StandardSymL embedded and then the Greek DELTA character is not shown. According to http://bugs.ghostscript.com/show_bug.cgi?id=694537#c2 it seems clear that the embedded StandardSymL font in doc.ps does not provide the Greek DELTA character or not as needed by the encapsulated PostScript diagram.eps. But what is strange (and this is the reason why I report it here) is: When doc.ps is sent directly (in so called "raw" mode) to some PostScript printers (e.g. HP LaserJet 1200), the PostScript printer prints the Greek DELTA character. I do not understand why (at least some) PostScript printers can print the Greek DELTA character but Ghostscript does not. I think this might indicate an issue in Ghostscript.
Created attachment 11180 [details] doc.ps
Created attachment 11181 [details] diagram.eps
This isn't a bug in gs, it's the result of how the files are constructed. The diagram.eps requests (does not embed) a font called "Symbol". When you run that file on its own, Ghostscript's default configuration maps the request for "Symbol" to "StandardSymL" (see Resource/Init/Fontmap.GS). The "StandardSymL" font that ships with Ghostscript contains the /Delta gylph, and thus it displays. 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". So the options are to configure Ghostscript with a different substitute for "Symbol" (which could easily result in the same issue occurring with different fonts). An obvious example would be if you make a "real" Symbol font available to GS, and the Postscript defined a subset font called "Symbol", the same problem would arise. Or to 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. 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. 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).
Chris Liddell, very many thanks for your instant and comprehensive explanation! Now it is perfectly clear for me what is going on and hereby I "verify" that it is no issue in Ghostscript.