Ghostscript head (r10626) and earlier versions cannot read the attached file, producing instead a "Error: /rangecheck in --run--" error. Based on output from -dPDFDEBUG this appears to be related to a CIDfont (see below). The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -o test.ppm ./44344.pdf Output from Ghostscript with -dPDFDEBUG: . . . %Resolving: [21 0] << /Subtype /Type0 /DescendantFonts [ 36 0 R ] /BaseFont /ZJHMCC+HiraMaruPro-W4 /Encoding /Identity-H /Type /Font >> endobj %Resolving: [36 0] << /Subtype /CIDFontType0 /FontDescriptor 34 0 R /BaseFont /ZJHMCC+HiraMaruPro-W4 /W 35 0 R /CIDSystemInfo << /Supplement 5 /Ordering (Japan1) /Registry (Adobe) >> /DW 1000 /Type /Font >> endobj %Resolving: [34 0] << /StemV 90 /FontName /ZJHMCC+HiraMaruPro-W4 /FontFile3 33 0 R /Flags 32 /MaxWidth 1673 /Descent -120 /FontBBox [ -393 -400 1280 1273 ] /Ascent 880 /CapHeight 783 /XHeight 558 /Type /FontDescriptor /ItalicAngle 0 /Leading 500 /AvgWidth 1000 /StemH 77 >> endobj %Resolving: [33 0] << /Subtype /CIDFontType0C /Length 36449 /Filter /FlateDecode >> stream %FilePosition: 877555 endobj %Resolving: [34 0] Error: /rangecheck in --run-- Operand stack: --dict:8/17(L)-- F7.1 1 --dict:5/5(L)-- --dict:5/5(L)-- ZJHMCC+HiraMaruPro-W4 -- dict:10/12(ro)(G)-- --nostringval-- CIDFontObject --dict:7/7(L)-- 391994 --dict:7/7(L)-- -- d Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push - -nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 Dictionary stack: --dict:1151/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- -- dict:108/127(ro)(G)-- --dict:289/300(ro)(G)-- --dict:22/25(L)-- --dict:6/8(L)-- -- dict:22/40(L)-- Current allocation mode is local
Created attachment 5905 [details] 44344.pdf
Created attachment 5906 [details] Bug691085.pdf Much reduced PDF file, this file now contains a single glyph in a single font I don't think this need be private. (it also runs *much* faster)
The problem is the CFF font parser, which is (as we know) written in PostScript. In gs_cff.ps we see: % Read other tables with queued offsets. % We process these in order so we can advance if needed. % The CFF file may not be positionable. { % outer loop since offsets may be updated when processing CFFDEBUG { (offsets: ) print [ offsets { pop } forall ] == } if [ offsets { pop } forall ] { lt } .sort % process in order of appearance { CFFDEBUG { (queued offset: ) print dup =print flush (, current pos=) print pos = } if /queued_offset 1 index def StringCache 1 index .knownget { /f exch 0 () /SubFileDecode filter def } { /f cff def dup pos ne { dup pos sub nextstring pop } if % negative advance will cause error I believe the problem is that one of the Font DICTs references a local Subrs DICT, and that *must* follow the Private DICT. However, having read the Private DICT we leap straight on to the next Font DICT. When we try to read the Subrs, we've already passed it, and thus have a negative offset, triggering the error above. Its not absolutely obvious from the CFF spec whether a CFF CIDFont should gather all the Font DICTs followed by all the Private DICTs followed by all the Local Subr INDEXes, or whether these should be interleaved. That is : FDSelect CharStrings[0] Font DICT[0] Private DICT[0] Local Subrs Index[0] CharStrings[1] Font DICT[1] Private DICT[1] Local Subrs Index[1] ... Or FDSelect CharStrings[0] CharStrings[1] ... Font DICT[0] Font DICT[1] ... Private DICT[0] Private DICT[1] ... Local Subrs Index[0] Local Subrs Index[1] The spec implies the latter, but I think this font does the former. Since Acrobat can deal with this font, I guess we will have to cater for both. This is going to be a big chunk of work, and I seem to remember that we were going to replace the PostScript CFF parser with a C parser. I don't want to start in on this qork if that's going to happen soon. Alex, any news on that ? I'll also need to upgrade my CFF disassembler which doesn't quite make it when dealing with this font.....
I've been working on CFF font parser for a week now. The number of differences in local regression is down to 200, mostly to OpenType fonts with CFF data, that are used as CIDFont resources.
Alex, should I reassign this issue to you ? There doesn't seem like any point in my looking further at it, you know the code much better than I do.
Is there any news on this? With latest built from trunk (9.00) I'm still seeing the same problem. Or is there a compile time switch to activate some new code?
The problem has been fixed by the new CFF parser, rev. 11749.