Customer document fails on page 182 with: /invalidfont in --@0x100194e0-- Attached are separate pdf files for page 181 (works ok) and 182 (no good). Reported against 8.51 on MS Windows, confirmed in HEAD on Linux.
Created attachment 2164 [details] last working page
Created attachment 2165 [details] broken page
The document embeds an incorrect True Type data for the font OBMKGG+H2gtrM. The True Type header specifies the size of 'loca' table equals to 12 bytes. In the sfnts array it is a separate string with the array index 2. Then it renders the glyph indes 3 accessing outside the loca table. It hapens rendering the text : /TT5 1 Tf 0.365 0 TD <0001>Tj Probably the problem happens because 2 font descriptors (43 obj and 38 0 obj, which correspond to local font names /TT4 and /TT5) refer same font data 39 0 obj. This data is an embedded font subset, which is enough for /TT4 and has no glyphs for /TT5. The error in Ghostscript happens because it doesn't check whether a glyph index points inside the 'loca' table and runs with occasional data taken past it.
Created attachment 2225 [details] patch.txt Attacxhing a patch. See log message in there. It is not ready for production< because it causes 9 regressions.
Perhaps, we also need to register a new operator to avoid printing the address.
Created attachment 2292 [details] patch1.txt An improved patch (being tested).
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2006-June/006632.html