Created attachment 1144 [details]
test.pdf

The error happens in TTF reader. The content of loca table of the font is not
increasing. This creates intervals >64K in /splitarray, which later causes
string operator to fail.

An attempt to sort the content of loca table solves the problem but
the file still fails with  /VMerror in --.type42execchar--

This is clearly a questionable TT font since the Apple TT font reference
manual clearly states that the length of glyphs can be inferred from
the difference in successive offsets.

That being said, I did modify the gs_ttf.ps and gstype42.c code to handle
this.

I assume that when Alex 'sorted' the loca table, he did not replace the
'loca' table that is subsequently stored in 'sfnts'. I did this and the
file ran, but as suspected the glyphs displayed were incorrect.

Note that the PostScript code only needs to deal with the sorted 'locatable'
in order to decide where to split the glyf strings in the sfnts array
(in the .dividesfnts proc). Otherwise the PostScript code doesn't care.

If the .dividesfnts uses a sorted locatable, but doesn't replace the 'loca'
table written into the sfnts, then the VMerror occurs because the C code
in 'default_get_outline' calculated the glyph_length for the gs_alloc
using loca table entries that might be out of order.

In order to effect the entire fix, I sorted the 'locatable' for the PS
code in .dividesfnts as well as creating a new 'len_glyphs' array in 
the gs_type42_data structure that holds the actual glyph lengths.
The glyph lengths are calculated once when the font is initialized in
gs_type42_font_init. If the 'loca' table is in order, then nothing
changes, but if it is out of order, we get the lengths by finding the
next higher glyph offset anywhere in the loca table.

These changes let the file run and show the same glyphs as Adobe Acrobat
Reader.

Patched gstype42.c Revision 1.49.