[gs-bugs] [Bug 691473] PDF 1.7 FTS: /limitcheck in --run--

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Thu Jul 22 16:05:31 UTC 2010


Chris Liddell <chris.liddell at artifex.com> changed:

           What    |Removed                     |Added
                 CC|                            |chris.liddell at artifex.com

--- Comment #3 from Chris Liddell <chris.liddell at artifex.com> 2010-07-22 16:05:29 UTC ---
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.

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list