Bug 690505 - Regression: More issues with pdfwrite and various nightly regression files
Summary: Regression: More issues with pdfwrite and various nightly regression files
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: master
Hardware: Macintosh MacOS X
: P2 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-29 21:33 UTC by Marcos H. Woehrmann
Modified: 2019-02-10 12:00 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2009-05-29 21:33:23 UTC
The following nightly regression files have issues with pdfwrite on peeves using head (r9772), the first 
two generate bad PDF files, the rest seg fault or generate a Ghostscript errror:

13-25.PS
16-04.PS

15-01.PS
15-02.PS
15-04.PS
15-10.PS
38-01.PS
Bug687546.ps


Other than the last file the following command can be used to duplicate the problems:

  gs -o test.pdf -sDEVICE=pdfwrite 13-25.PS


The last file only fails if both -dNOOUTERSAVE -dJOBSERVER are specified:

  gs -o test.pdf -sDEVICE=pdfwrite -dNOOUTERSAVE -dJOBSERVER Bug687546.ps
Comment 1 Marcos H. Woehrmann 2009-05-30 07:37:38 UTC
Another file that generates a bad PDF File:

15-03.PS
Comment 2 Ken Sharp 2009-07-10 07:43:57 UTC
Well, the reason 13-25 (and probably other tests) exits is because of this line
in the 'Global_Interference_Test':

      (/work34{ { quit } stopped iff { stop } stopped iff { } stopped not iff })

If we run without a job server loop then this terminates Ghostscript
immediately. This works OK in that it produces output, but it means we exit
having run less than half of this group of tests. I'd suggest we *always* want
to run the Genoa test files with -dJOBSERVER to avoid this.

The actual problem, however, is due to an earlier pair of tests:

      (/look05{ { /o glyphshow pop pop pop } (WiWi) cshow })
      (/look06{ /G glyphshow /T glyphshow })

The execution of glyphshow seems to be resetting the pdfwrite device in some
sense, the output stream is reset to 0 and the xref seems to be discarded. Now
to find out why....

Comment 3 Ken Sharp 2009-07-13 06:52:23 UTC
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.

Comment 4 Ken Sharp 2009-07-13 08:01:30 UTC
Running the other files (except Bug687546.ps) with -dJOBSERVER produces errors,
generally /unregistered (without -dJOBSERVER the jobs conclude with 'stuff' on
the stack).

I believe these are all due to some problem processing Type 3 fonts, mostly due
to using glyphshow but some of the tests may be using cshow or similar
procedural show operations causing a similar problem.
Comment 5 Ken Sharp 2009-07-14 05:43:04 UTC
15-01.ps, 15-02.ps and 15-04.ps are more examples of the same problem as 13-25.ps. 

15-02 and 15-04.ps use the glyph named ~071 (15-01.ps uses ~067) which doesn't
exist in the font, so we get an error. The test is executed in a stopped context
so we don't see an error.

However pdfwrite is still writing into a substream. In this case the job
continues, but the graphics state stack (amongst other things) is no longer
correct, and eventually the whole thing fails with an 'unregistered' error.

Comment 6 Ken Sharp 2009-07-14 06:43:15 UTC
16-04.ps is yet another example, in this case the type 3 font has names of the
form /~xxx where xxx is a 3 digit number. The test string consists of        
(0A1B2C3D4E5F6G7H8I9J).

While capturing the charproc we get an error (typecheck on cvr in this case),
again this test is executed in a stopped context, so the interpreter carries on,
but pdfwrite still thinks it is capturing a type 3 glyph procedure for the
remainder of the job.

15-10.ps is the same again, an attempt to use a character code greater than the
length of the Encoding array. The Encoding array is defined as 128 elements
(0->127), the test tries to use character codes 128,129,130,131 and 132. As
usual this test is executed in a stopped context, this fails in exactly the same
way as all the other type 3 font error handling.

Comment 7 Ken Sharp 2009-07-15 06:09:53 UTC
38-01.ps exhibits a problem with pdfwrite. The job tries to use a glyph which is
not present in the font. pdfwrite calls the font 'encode_char' method which
returns a 0 code (no error) but sets the glyph name to gs_no_glyph to indicate
that the glyph could not be found.

The code then tried to use this name to get the glyph info, which caused a
segment fault. Fixed by detecting the condition and returning an error.

Patch here:
http://ghostscript.com/pipermail/gs-cvs/2009-July/009558.html
Comment 8 Ken Sharp 2009-07-15 06:39:27 UTC
I'm unable to reproduce any problem with the file bug687546.ps. I've tried with
and without -dJOBSERVER and -dNOOUTERSAVE on both Windows and Fedora. In all
cases the job completes without error.
Comment 9 Marcos H. Woehrmann 2009-08-05 13:25:49 UTC
I've disabled these files in the repository, please re-enable when the problem is resolved.
Comment 10 Marcos H. Woehrmann 2009-08-05 13:31:28 UTC
I can no longer duplicate the issue with Bug687546.ps, I'm leaving it enabled in the regression files.
Comment 11 Ken Sharp 2019-02-10 12:00:18 UTC
Looks to me like these have all been tackled.