File fts_23_2306_a4.pdf fails with Error: /limitcheck in --run-- and a number 312494 on top of the operand stack. Probably, it's another clash between PDF and PS architectural limits.
Update to reflect customer status and ID.
The error happens somewhere in /.dividesfnts . Do we still need this procedure with FreeType? When it's disabled, the sample file runs to completion, and regression testing shows no differences.
I found what's causing the error in .dividesfnts: it will only split the strings when the split offset is even, and we get a *long* run of cases where the split offsets are odd. When we finally reach an even offset again, we've "buffered up" *way* too much data to fit in a string, then we try to make a string for it to fit in - rangecheck! To resolve this would be a lot of work: it would mean removing the requirement of only splitting on even offsets by padding strings as necessary and recalculating the loca table to reflect the new offsets. But, like Alex, I am baffled as to the (present) need for .dividesfnts. The job in question contains a very large Type 11 font, and both the Freetype code and the GS internal code handle it fine with the contents of .dividesfnts removed. Both the Freetype build, and the non-FT build run correctly on the cluster without .dividesfnts. As for other "consumers", pdfwrite will "recreate" a Truetype font, ps2write includes procedures to create a well formed Type 42 from a TrueType, and pswrite doesn't write fonts, as I understand it. I think the requirement for .dividesfnts disappeared with the introduction and use of string_array_access_proc() way back in revision 176, and is now serves no useful purpose - in fact, given that it's doing a pretty complex thing, it probably slows us down! My vote is we remove .dividesfnts.
I am in favor of getting rid of .dividesfnts as well.
Created attachment 6535 [details] patch Remove .dividesfnts procedure.
The patch has been committed as a rev. 11539.
Changing customer bugs that have been resolved more than a year ago to closed.