Bug 690164

Summary: Ghostscript generated pdf file not correctly read by Ghostscript nor Acrobat 9.0
Product: Ghostscript Reporter: Marcos H. Woehrmann <marcos.woehrmann>
Component: PDF WriterAssignee: Ken Sharp <ken.sharp>
Status: NOTIFIED FIXED    
Severity: normal    
Priority: P1    
Version: master   
Hardware: Macintosh   
OS: MacOS X   
Customer: 1110 Word Size: ---

Description Marcos H. Woehrmann 2008-11-08 17:16:26 UTC
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
Comment 1 Marcos H. Woehrmann 2008-11-08 17:17:10 UTC
Created attachment 4588 [details]
textoverprint.ps
Comment 2 Ken Sharp 2008-11-12 01:57:59 UTC
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 ?

Comment 3 Ken Sharp 2008-11-12 02:06:47 UTC
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.
Comment 4 Ken Sharp 2008-11-27 08:03:10 UTC
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.