[gs-bugs] [Bug 690505] Regression: More issues with pdfwrite and various nightly regression files

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Mon Jul 13 06:52:23 PDT 2009


http://bugs.ghostscript.com/show_bug.cgi?id=690505





------- Additional Comments From ken.sharp at artifex.com  2009-07-13 06:52 -------
Well, for 13-25.ps the problem is caused by the fact that we get an error in a
type 3 font BuldGlyph (rangecheck in getinterval), while accumulating the
procedure. This is trapped by a customer error handler which simply continues
(noting the error in passing).

However, pdfwrite has started storing the data in a substream, and because it
never sees the end of the BuildGlyph it simply continues storing the job in the
substream.

I don't think there is any real way for pdfwrite to recover from this kind of
error. The error and the error handling all take place in the PostScript
interpreter, pdfwrite gets no notification that there has been a problem and I
don;t think has any way to determine the difference between a stream of
operations composing a glyph, and a stream of operations after an error inside a
glyph.

The only way I can see to deal with this would be to handle all type 3 fonts by
conversion to bitmap, instead of creating a scalable outline. That works, but
its ugly. (it works because we don't create a substream to hold the charproc)

The problem is that the BuildGlyph procedure expects a glyph name of the form
/~xxx where xxx is a 3-digit number. Glyphshow sends the name /G, the BuldGlyph
converts the glyph name to a string and executes a 1 3 getinterval on the
string. Since the glyphshow has only a single byte in the string, it fails with
a rangecheck.





------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.



More information about the gs-bugs mailing list