The customer reports and I've verified that the attached generates an error with gshead (r8296): GPL Ghostscript SVN PRE-RELEASE 8.61: Failed to interpret TT instructions in font 80000006. Continue ignoring instructions of the font. Error: /invalidfont in --run-- Both Acrobat Reader (v7.0) and evince display this file correctly, evince does generate several warnings: "some font thing failed" (even more cryptic than our messages :-). The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -sOutputFile=test.ppm ./A2.32_Floor_Plan_Level-2x.PDF
Created attachment 3475 [details] A2.32_Floor_Plan_Level-2x.PDF
This is probably similar to 689471.
Per request I'm retesting this customer's bugs: this one still occurs with r8596.
support has requested a status update for this problem. Please add a new comment entry or send mail to Marcos.
The test document embeds a TT font, in which numGlyphs=5 and loca length = 28. This may be obtained when running with -ZY. The failed condition is gstype42.c ln 518 : if (glyph_index >= pfont->data.trueNumGlyphs) return_error(gs_error_invalidfont); So I've got an idea how to work around : when loading a font. check if numGlyphs is smaller than locaa length. If so< chech whether all loca entries are correct. If so, fix numGlyphs and print warning. I'm not sure that it will work fine, but chances look pretty good. So at this point we can talk to the customer that the document is incorrect, and we're trying to develop a workaround.
The suggested change works and passed the regression test with comparefiles, so I'll commit it soon.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-May/008354.html