| Summary: | Ghostscript does not show character from embedded font (Greek DELTA from StandardSymL) but PostScript printers do | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | jsmeix |
| Component: | General | Assignee: | Default assignee <ghostpdl-bugs> |
| Status: | NOTIFIED INVALID | ||
| Severity: | normal | CC: | chris.liddell |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
doc.ps
diagram.eps |
||
|
Description
jsmeix
2014-09-23 01:02:22 UTC
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. |