Bug 8180

Created attachment 6870 [details]
A c-program that illustrates the problem.

Created attachment 6871 [details]
Makefile for compiling caps.c

Created attachment 6872 [details]
PostScript file output by caps

Created attachment 6873 [details]
PostScript file output by paps-0.6.6 for comparison

Created attachment 6874 [details]
GhostScript rendering of caps.ps

While I'm at it, why is the font size so much bigger in the caps output? The
caps glyph size is a lot bigger than the 12 points that I requested.

Thanks Dov.  I confirmed that this is only happening with the TrueType
subsetting code, and for that, it looks an awful like the FreeType equivalent of
bug 7603.  CCing Adrian and Kristian.

(In reply to comment #6)
> While I'm at it, why is the font size so much bigger in the caps output? The
> caps glyph size is a lot bigger than the 12 points that I requested.

Because you don't set a resolution on your pangocairo context, and it assumes a
96 dpi, while pangoft2 backend defaults to 72 I guess.

I'm not sure if it would be better if we used 72 for cairo's PS/PDF backend.  A
default value that depends on the target surface would be a bit confusing.

(In reply to comment #8)
> (In reply to comment #6)
> > While I'm at it, why is the font size so much bigger in the caps output? The
> > caps glyph size is a lot bigger than the 12 points that I requested.
> 
> Because you don't set a resolution on your pangocairo context, and it assumes a
> 96 dpi, while pangoft2 backend defaults to 72 I guess.

I agree that it's confusing to use the word dpi in the context of ps/pdf to mean
something quite different.  In Pango world, the dpi/resolution is used to
convert between point units and device units.  So, for a PS/PDF backend, this is
always 72.

(In reply to comment #7)
> Thanks Dov.  I confirmed that this is only happening with the TrueType
> subsetting code, and for that, it looks an awful like the FreeType equivalent of
> bug 7603.  CCing Adrian and Kristian.

I can reproduce the clipping problem with this font without pango. It depends on
the version of ghostscript. 8.15 has the problem. Later versions don't.

The problem seems to occur with fixed width truetype fonts. This suggests a
possible problem with the hmtx table.

Testing.

(In reply to comment #10)
> (In reply to comment #7)
> > Thanks Dov.  I confirmed that this is only happening with the TrueType
> > subsetting code, and for that, it looks an awful like the FreeType equivalent of
> > bug 7603.  CCing Adrian and Kristian.
> 
> I can reproduce the clipping problem with this font without pango. It depends on
> the version of ghostscript. 8.15 has the problem. Later versions don't.
> 
> The problem seems to occur with fixed width truetype fonts. This suggests a
> possible problem with the hmtx table.
> 

There seems to be a problem with adding attachments so I will just paste in here.

There was a problem the the horizontal metrics table being written by the
truetype subsetting when a fixed width font is used. This would result in
incorrect left side bearings in the subsetted font. This patch fixes the problem.

diff --git a/src/cairo-truetype-subset.c b/src/cairo-truetype-subset.c
index c5e1799..7882d21 100644
--- a/src/cairo-truetype-subset.c
+++ b/src/cairo-truetype-subset.c
@@ -591,7 +591,7 @@ cairo_truetype_font_write_hmtx_table (ca
             }
             font->backend->load_truetype_table
(font->scaled_font_subset->scaled_font,
                                                 TT_TAG_hmtx,
-                                                (num_hmetrics - 1) *
long_entry_size +
+                                                num_hmetrics * long_entry_size +
                                                 (font->glyphs[i].parent_index -
num_hmetrics)
                                                                           *
short_entry_size,
                                                 (unsigned char *) (p+1),
&short_entry_size);
-- 

The patch improves it, but doesn't quite fix it.  'w's are still clipped here.

I've added before/after shots here:  http://www.gnome.org/~behdad/tmp/

Mail and attachments seem to be broken.

I have tried several versions of ghostscript and can only reproduce the clipping
problem using ESP Ghostscript 8.15.1. There is a bug report against this version
for a glyph clipping problem:

http://www.cups.org/espgs/str.php?L1831

The bug has been recently fixed in the Subversion repository. I have tested the
current ESP Ghostscript source in Subversion and the clipping problem does not
occur. The Subversion log for the bug fix states that some new TrueType bounding
box code has been disabled because it was causing problems.

Thanks Behdad and Adrian for all the investigations and for verifying that it is
not a cairo bug! It has also convinced me to hold off converting paps to using
cairo until ghostscript has been updated on the major platforms.

Behdad, what do you think about adding caps.c to the pango/examples directory
under the name cairo-ps.c .

Should I close the bug as NOTABUG?

(In reply to comment #16)
> Thanks Behdad and Adrian for all the investigations and for verifying that it is
> not a cairo bug! It has also convinced me to hold off converting paps to using
> cairo until ghostscript has been updated on the major platforms.
> 
> Behdad, what do you think about adding caps.c to the pango/examples directory
> under the name cairo-ps.c .

I'm definitely interested.  I actually was going to do something like that when
I find the time.  I talked about it in more details here:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192912

In short, I wanted to extend pango-view to do it, but thinking about it now, I
agree that not much code can be shared between them.  We may be able to share
the code in renderdemo.c still.  I personally prefer to call it pango-u2ps, or
something similar.  Just opened a bug for it:

  http://bugzilla.gnome.org/show_bug.cgi?id=355368

> Should I close the bug as NOTABUG?

I think Adrian's patch should be committed regardless.  It would be interesting
to see if we can work around the bug too.

Adrian, are you going to commit the patch?

I committed the patch:

http://gitweb.freedesktop.org/?p=cairo.git;a=commit;h=f9165638bf485591abae52b759fba82caf048dc5

I'm pretty sure the rest of this problem is a ghostscript problem.  See

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194592

In particular, postscript output from gnome-print and openoffice has similar
problems and there appears to be a problem with ghostscripts glyph bounding box
code in 8.15.2.

Created attachment 8009 [details]
UTF-8 stress test file

I just checked the state of this bug on Fedora Core 6 and indeed the postscript
rendering with the string embedded in caps.c is fixed.

But I then went on to test the rendering of a file that I received through the
paps mailing list called testpaps, that is basically a UTF8 stress test. The
resulting postscript has several rendering mistakes.

I didn't update pango, but my guess is that it is not a pango problem, as it
does not produce postscript directly...

Test it with:

    ./caps testpaps > testpaps.ps
    gs -dNOPLATFONTS -sDEVICE=x11alpha	-sPAPERSIZE=a4 testpaps.ps

In the end there were two characters that were rendered wrong by ghostscript:

    Άό

But it turns out that this was yet another bug in the fc6 ghostscript, version
8.15.3, that render some characters garbled in the Type42 font. 

I verified this by doing the following:

1. Turned the embedded font into a valid ttf file which I loaded into fontforge. 
2. Created pdf file which renders correctly in gpdf and in acroread, but not in
ghostscript.

Thus cairo is ok, but I am still hesitant of turning paps into using cairo as
long as such problems persist in ghostscript...

Too bad.  These GhostScript bugs make much of Adrian's work in all the different
subsetting stuff less than perfectly usable.  We probably add API to
enable/disable various subsettings.  At that point you can turn TrueType off and
most probably be happy with it.

FYI, I opened up a ESP Ghostscript bug about the rendering problem at:

   http://www.cups.org/espgs/str.php?L2180+P0+S-2+C0+I0+E0+Q

(In reply to comment #22)
> Thus cairo is ok, but I am still hesitant of turning paps into using cairo as
> long as such problems persist in ghostscript...

So what would cairo need to do differently (that presumably paps is doing) in
order to generate PostScript that would be rendered properly by more versions of
ghostscript?

-Carl

paps is not generating TrueType subsets.  It does Type3 at best, but last time I
checked it was not even doing that.

Yes, that's right, Behdad. The development of paps was as follows:

1. Long postscript where every character was decomposed as explicit postscript
drawing primitives.

2. I turned each character into a postscript def and referenced these
definitions by name, and suitable moveto's were done in between.

3. Compression of the moveto and character drawing statements into encoded
strings that during drawing are decomposed into moveto and nte character drawing
defs.

I realized that I could get it more compressed by doing Type 3 and Type 1 fonts,
but I never got that far, before I cairo showed me the light. :-)

Of course as far as the postscript engine is concerned Type 3 and my explicit
drawing of the primitives are equivalent. Thus I believe a suitable workaround
to the current ghostscript bugs would be to generate Type 3 fonts.

Cairo already has code to do Type3 fallback, Type1 fallback, Type1 subset, and
TrueType subset.  So, it's just a matter of choosing the right now.  Right now
it tries them in the reverse order of what I listed.  So, for a TrueType font,
you get a TrueType subset.  This is supposedly superior to the other methods, as
it allows for subsetting hinting instructions, etc. (at least theoretically. 
Not sure if we do that right now.)

So, I suggest:

  - Go ahead and write caps, as part of pango preferably.  Or keep it separate
if you prefer.  I suggest adding the functionality to the pango-view code.  Now
that gnome has moved to svn, we can actually rename files to better reflect the
code there, and move them out of examples/ for example.

  - Add API to cairo to allow enable/disabling certain subsetters.

  - Add parameters to caps to choose which subsetters to use.

Now I remember Adrian saying that TrueType subset is in fact not part of the
Postscript standard at the level cairo produces (2?).  Another option is to add
a cairo_ps_restrict_to_version (ala the svg one) and use that to decide which
subsetters to use, but then again, Adrian tells me that Postscript printers have
a separater setting for whether they accept TrueType subsets, and that's encoded
in their PPD file, regardless of the language level they accept.  So maybe the
separate knob is needed anyway.

If we want to get new API in, we better be fast, or have to wait a few months.

Dov, any progress has been made here?

Closing this because

- The Ghostscript bug was fixed a long time ago and most distributions should have the bug fix by now.

- "Add API to cairo to allow enable/disabling certain subsetters" is on the cairo TODO list.