This file has a problem, but it causes GS to exit with an error. The FontFile2 for an embedded TrueType font is a zero length stream. Examination with a hex editor shows that at the file offset is 'endstream' then 'endobj' (for object 439). We don't handle this gracefully. PDFDEBUG output shows: %Resolving: [437 0] << /Type /Font /Subtype /TrueType /BaseFont /NOTFVW+Palatino-Roman /Name /Rx201 /FirstChar 0 /LastChar 255 /Widths 442 0 R /Encoding 441 0 R /FontDescriptor 438 0 R >> endobj %Resolving: [438 0] << /Type /FontDescriptor /FontName /NOTFVW+Palatino-Roman /FontBBox [ -227 -278 1089 920 ] /Flags 32 /Ascent 732 /Descent -7717 /Leading 1000 /CapHeight 732 /XHeight 0 /AvgWidth 508 /MaxWidth 1143 /MissingWidth 0 /ItalicAngle 0 /StemV 73 /StemH 0 /FontFile2 439 0 R >> endobj %Resolving: [439 0] << /Length 440 0 R /Filter [ /FlateDecode ] >> stream %Resolving: [440 0] 0 endobj %FilePosition: 198735
Created attachment 4181 [details] PDF_For_Artifex.pdf This file fails on Page 8. -dFirstPage=8 can be used to get the failure immediately.
Fix a bug in the error recovery code that handles invalid font streams. The following patch is committed as a rev. 8820. http://ghostscript.com/pipermail/gs-cvs/2008-July/008402.html Regression testing shows no differences. A file that exercises this case will be added to the test suite.