[cairo] [PATCH]A cairo-ps-surface.c issue for modern finicky versions of ghostscript

[Adrian Johnson]

Alan W. Irwin wrote:
> There is actually one other PostScript issue for cairo-1.4.12 (and previous)
> that the extensive set of PLplot examples has revealed when the results are
> interpreted with ghostscript 8.56 (and later).
> 
> Here is the typical 'gv --noquiet' error message assoicated with
> this non xyshow issue.
> 
> Error: /typecheckGPL Ghostscript 8.56: Unrecoverable error, exit code 1
>   in definefont
> Operand stack:
>     CairoFont-4-0   --dict:8/10(L)--   Font
> Execution stack:
>     %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1797   1   3   %oparray_pop   1796   1   3   %oparray_pop   1792   1   3   %oparray_pop   1675   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1765   2   3   %oparray_pop
> Dictionary stack:
>     --dict:1086/1123(ro)(G)--   --dict:0/20(G)--   --dict:80/200(L)--
> Current allocation mode is local
> Last OS error: 2
> 
> Now "definefont" occurs throughout our ~30 different pscairo results, but
> the three examples that have the above error have a special signature for
> definefont that can be grepped for as follows:
> 
> irwin at raven> grep '>> definefont pop' *.pscairo
> x07c.pscairo:>> definefont pop
> x23c.pscairo:>> definefont pop
> x23c.pscairo:>> definefont pop
> x24c.pscairo:>> definefont pop
> 

I downloaded and built the svn version of PLplot to have at look at what
is going on. The '>> definefont pop' code is only used for bitmap fonts
which are embedded as Type 3 fonts. x24c.pscairo is the only test output
I found that contained a Type 3 font. Using 1.4.12 and gs 8.56 I can
reproduce the problem.

It is useful to understand how cairo embeds fonts in PostScript to be
able to debug font problems. For each font used, cairo always embeds a
subsetted font containing only the glyphs used. This ensures the
PostScript output will be identical to the display output and avoids
problems with substituted fonts with different metrics or missing glyphs.

TrueType fonts are subsetted and wrapped in a Type 42 font dictionary
that looks like:

11 dict begin
/FontType 42 def
[ ....]
/sfnt [ /* TrueType font in AsciiHex */ ]


Type 1 fonts are copied to the PostScript output after stripping out
unused glyphs.

%!PS-AdobeFont-1.0: NimbusSanL-Regu 1.05
[ ... ]
/FontType 1 def
[ ... ]


Any other outline font such as OpenType/CFF is embedded as a Type 1 font
that cairo creates from the glyph outlines.

%!FontType1-1.1 CairoFont-0-0 1.0
11 dict begin
/FontName /CairoFont-0-0 def
/PaintType 0 def
/FontType 1 def


Bitmap fonts are embedded as a Type 3 font that cairo creates from the
glyph bitmaps.

/CairoFont-1-0 <<
        /FontType 3
[ ... ]

> That signature is defined in src/cairo-ps-surface.c for the cairo-1.4.12
> release.  I don't have enough understanding of PostScript to
> figure out why gv is complaining about the type
> of (presumably) the various objects that make up the font, but I did notice
> that Adrian had reworked this area of the code for a git commit entitled
> 
> PS: Make Type 3 fonts text selectable
> 
> I don't think the above issue has anything to do with Type 3 fonts, but
> nevertheless since he reworked the area, I thought there was a good chance
> that the above issue would be fixed regardless of the motivation of the
> change, and that turned out to be the case!

I have been fixing some bugs and missing features in Type 3 font
embedding while working on getting Windows bitmap fonts to work with the
PostScript and PDF backends.

I did some testing to work out why the above commit fixed the problem.
It looks like ghostscript 8.56 requires the encoding vector to be filled in.

In 1.5.3 I changed this to store the Unicode names of the glyphs to
facilitate text extraction from PostScript files that have been
converted to PDF. 1.4.x does not have the code for obtaining the glyph
names however I will commit a modified version of this patch to the 1.4
branch that uses the fallback glyph naming eg "/g123".

> A word of explanation.  Our range of examples is so extensive that we
> exercise the font system pretty hard.  There is clearly some issue with the
> Debian testing fonts for the above three examples (x07c.pscairo,
> x23c.pscairo, and x24c.pscairo). For the 24th example which is a "peace"
> flag, the Korean word for peace is displayed at roughly one-tenth size for
> our xcairo and pngcairo results and as blank for our pscairo results
> generated with the patched cairo and also as a blank for pdfcairo.  I am
> virtually positive it is this font issue that generates the special
> definefont signature that caused the trouble and which had to be patched.
> Thus, you could say that debian testing problems with fonts give a unique
> opportunity to explore how cairo responds to such font errors.  :-) The X,
> png, pdf, and patched PostScript back ends of cairo are okay under these
> difficult testing circumstances, but the PostScript back end for the vanilla
> cairo-1.4.12 produces files which modern gv/ghostscript does not like under
> these circumstances.

Is there an automated way to check the PLplot test results?

> I suggest for your forthcoming release that you at least include the three
> PostScript backend patches above which give good results with no
> gv/ghostscript errors for the extensive PLplot testing of that backend.

I am doing further testing with latest ghostscript version and will
commit fixes to both the 1.4 and 1.5 branches.