The customer reports and I've confimred that the attache PDF file generates an error with gs8.62 and gshead (r8825), however earlier versions of Ghostscript (e.g. 8.54) read the file without error. Running search-svn-revs says that r6842 was the revision that broke this. The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -sOutputFile=test.tif ./page1
Created attachment 4209 [details] page1.pdf
Even though there is code elsewhere in lib/gs_ttf.ps that seems intended to substitute /.notdef for null glyphencodings, it is still managing to filter down to the code at line 1741 with null in the array. The patch below allows the file to open, but there may be another better way to fix this. *** lib/gs_ttf.ps Tue Jun 10 12:10:54 2008 --- ./gs_ttf.ps Thu Jul 10 12:34:06 2008 *************** *** 1741,1747 **** % Add glyphs of 'post' with lower priority : 0 1 glyphencoding length 1 sub { ! dup glyphencoding exch get exch dup 0 ne { 3 copy pop known not { 3 copy put --- 1741,1749 ---- % Add glyphs of 'post' with lower priority : 0 1 glyphencoding length 1 sub { ! dup glyphencoding exch get ! dup //null eq { pop /.notdef } if ! exch dup 0 ne { 3 copy pop known not { 3 copy put Assigning to Alex for review of the above patch, or for another fix.
Created attachment 4211 [details] patch Don't generate an array of nulls in the first place. This saves the trouble of checking for null values later. Regression testing shows no differences. Sample files from bug 689495 and bug 689707, which depend on the modified code, still work OK.
Use /.notdef instead of null in the array of PostScript names of TTF glyphs. This saves the trouble of checking for null values and fixes a case where a null entry slipped through. The patch (comment #3) is committed as a rev. 8837.