Bug 690164

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.