Comment # 24 on bug 897284 from Johannes Meixner

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.