[gs-bugs] [Bug 691573] invalidfont in xshow

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Tue Aug 24 13:54:19 UTC 2010


http://bugs.ghostscript.com/show_bug.cgi?id=691573

Ken Sharp <ken.sharp at artifex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Ken Sharp <ken.sharp at artifex.com> 2010-08-24 13:54:16 UTC ---
The problem is that the font really is invalid, for the purposes of copying,
but not for the purposes of rendering.

When copying the embedded type 42 (TrueType, nearly) fonts, pdfwrite starts by
copying the /.notdef glyph, which is required for all fonts. 

It does this by finding the glyph ID (GID). To do that, it searches the
CharStrings dictionary, in a type 42 font there should be a unique mapping
between the glyph name and the GID. Each glyph should be stored by name in the
CharStrings dictionary and the associated value should be the GID of that
glyph.

The PostScript code contains this:

/CharStrings 256 dict dup begin
0 1 255{/.notdef exch def}for

That treats the CharStrings dictionary as if it were an array (like the
Encoding) and puts the glyph name /.notdef in the CharStrings dictionary 256
times, with the values 0 to 255. *HOWEVER* because dictionary entries are
indexed by name, only the last entry actually has any effect, which stores the
value 255 for the name /.notdef.

This is technically invalid, since TrueType fonts have the /.notdef at GID 0.
However, what's worse is that the font's sfnts array doesn't contain an entry
for GID 255, so we are unable to copy that glyph when we try to copy the
/.notdef entry, and so we emit an invalidfont error.

This doesn't occur when rendering, because the /.notdef glyph is only used (as
the name implies) when an error would otherwise occur because a glyph is not
defined. Since all the glyphs used are defined in the font, the /.notdef is not
used, and so no error occurs. Its trivial to show that if a glyph is used which
is not present in the font, that an invalidfont also occurs when rendering.

So fundamentally the problem is that the embedded fonts are invalid, which is
why we generate an invalid font error. However Adobe Acrobat Distiller will
create a PDF file from this input. In an attempt to duplicate this behaviour I
have modified the font copying code so that if we fail to copy a glyph, and the
glyph name is /.notdef and the GID is non-zero, we attempt to copy the glyph
with GID 0 instead. If that fails we still error out.

This works with the supplied file, but is not guaranteed to work under all 
conditions. However, since the font genuinely *is* faulty this is probably as
good as we can get.

David, given the content of the EPS file, and your address at 'biomedcentral' I
assume you are registered users of the GraphPad Prism software which was used
to create this file. I would very much appreciate it if you would raise this
issue with technical support at GraphPad Software. If someone at GraphPad would
like more details than are in this thread then I would be happy to discuss the
issue further with them. It is possible that 5.03 of the software does fix this
problem of course.


Fixed in revision 11652, patch here:

http://ghostscript.com/pipermail/gs-cvs/2010-August/011666.html

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list