The attached PostScript file when converted to a PDF file with gs8.63 or gshead (r9211) is not correctly converted to tiff32nc by Ghostscript nor read by Acrobat 9.0 (Apple Preview and Acrobat 8.1 read the file correctly). Converting the PostScript file directly to tiff32nc or converting it with Distiller 9.0 works as expected (as does converting the PDF file to tiff24nc). The command lines I'm using: bin/gs -sDEVICE=pdfwrite -o test.pdf ./testoverprint.ps bin/gs -sDEVICE=tiff32nc -o test.tif ./test.pdf
Created attachment 4588 [details] textoverprint.ps
This is a truly icky file from Quatk Xpress. The text is set in Quarks dreadful type 3 font, which it uses for all 'special effects', such as artificial emboldening, or in this case different stroke and fill colours. This is done by constructing a type 3 font whose BuildChar first 'show's the glyph normally, then executes a 'charpath stroke' to draw the outline. It uses the parent font (Helvetica in this case) for the outlines. The body of the job has overprint set to true, but the type 3 font explicitly sets overprint to false before the initial text for the fill. It does this inside a gsave/grestore pair, so the grestore puts overprint back to being true, just before it strokes the outline. Basically: gsave false setoverprint (A) show grestore (A) charpath stroke The problem for us is that we start the type 3 charproc as a new stream, and we assume that all the graphics state parameters are at their defaults, in the case of overprint this means 'false'. By the time we see the text, the overprint is set to false, so we do nothing. NB this is itself incorrect! If we write the font this way, then the glyph will inherit the overprint setting from the parent stream and will *still* overprint in this case, since the parent stream has overprint set to true. We then see the 'stroke', but the grestore has set the overprint back to true now. Because we assumed the overprint was false when we started, we emit a 'true' setoverprint. Now, a show followed by a charpath stroke is currently converted into a show with a non-zero text rendering mode. The fact that we have set overprint to true means that we end up emitting a gstate where overprint is true. Solving this is tricky. We need to set the overprint to 'false' for the type 3 font, because it is explicitly set this way in the BuildChar. We then need to set it back to true for the stroke. The only way I can do this at present is by not combining the show+charpath into a single text rendering operation. I'm running regression tests, but this seems to work. However.... I can't see any way to tell the difference between a type 3 font which explicitly sets overprint, and one which simply inherits the overprint setting from the current graphics state. For example, if the type 3 font simply uses the current setting then it will behave differently if the content stream sets overprint to true, shows a glyph, then sets it to false and shows the same glyph. A type 3 font which explicitly sets the overprint (as we now do) will show the glyph the same way, no matter what the setting of overprint in the stream which uses it. How do we tell during the course of capturing a type 3 font that it has explicitly set the overprint ?
Second thoughts, if we set up the graphics state parameters at the start of the type 3 stream to match those in the parent at the moment the glyph is shown, then we can determine which state parameters have changed. Since we now know which parameters have changed, it should be OK to write those as required. I'll look into this as part of the text rendering changes.
The patch: http://ghostscript.com/pipermail/gs-cvs/2008-November/008827.html In conjunction with several other patches (especially including revision 9196) should resolve this issue. Please note, this relies upon the existence of several previous fixes for text rendering modes, outline fonts etc, I would not attempt to apply this patch in isolation, a full update to revision 9248 is recommended. There is still a problem, not exhibited by this file which I'll bring up at the staff meeting.