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
Another file that generates a bad PDF File: 15-03.PS
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....
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.
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.
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.
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.
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
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.
I've disabled these files in the repository, please re-enable when the problem is resolved.
I can no longer duplicate the issue with Bug687546.ps, I'm leaving it enabled in the regression files.
Looks to me like these have all been tackled.