Bug 8180 - API to enable/disable PS font subsetting (e.g. optionally disable Type42 etc)
Summary: API to enable/disable PS font subsetting (e.g. optionally disable Type42 etc)
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: postscript backend (show other bugs)
Version: 1.2.4
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-07 14:27 UTC by Dov Grobgeld
Modified: 2008-10-11 02:13 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
A c-program that illustrates the problem. (3.17 KB, text/x-csrc)
2006-09-07 14:28 UTC, Dov Grobgeld
Details
Makefile for compiling caps.c (140 bytes, application/octet-stream)
2006-09-07 14:29 UTC, Dov Grobgeld
Details
PostScript file output by caps (42.27 KB, application/postscript)
2006-09-07 14:30 UTC, Dov Grobgeld
Details
PostScript file output by paps-0.6.6 for comparison (14.91 KB, application/postscript)
2006-09-07 14:32 UTC, Dov Grobgeld
Details
GhostScript rendering of caps.ps (14.97 KB, image/png)
2006-09-07 14:36 UTC, Dov Grobgeld
Details
UTF-8 stress test file (1.55 KB, text/plain)
2006-12-08 04:41 UTC, Dov Grobgeld
Details

Description Dov Grobgeld 2006-09-07 14:27:57 UTC
I am not sure whether this is a pango bug or a cairo bug, but a rough guess
makes me believe this is a cairo postscript output bug.

I'm getting clipped and non-uniform glyph widths when using the monotype font
DejaVu Sans Mono 12 .

I'm using cairo distribution 1.2.4 .

As a comparison, paps works just fine with this font.

I'm attaching several fies that illustrate the problem.
Comment 1 Dov Grobgeld 2006-09-07 14:28:51 UTC
Created attachment 6870 [details]
A c-program that illustrates the problem.
Comment 2 Dov Grobgeld 2006-09-07 14:29:23 UTC
Created attachment 6871 [details]
Makefile for compiling caps.c
Comment 3 Dov Grobgeld 2006-09-07 14:30:47 UTC
Created attachment 6872 [details]
PostScript file output by caps
Comment 4 Dov Grobgeld 2006-09-07 14:32:15 UTC
Created attachment 6873 [details]
PostScript file output by paps-0.6.6 for comparison
Comment 5 Dov Grobgeld 2006-09-07 14:36:32 UTC
Created attachment 6874 [details]
GhostScript rendering of caps.ps
Comment 6 Dov Grobgeld 2006-09-07 14:38:58 UTC
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.

Comment 7 Behdad Esfahbod 2006-09-08 07:23:21 UTC
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.
Comment 8 Behdad Esfahbod 2006-09-08 07:25:59 UTC
(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.
Comment 9 Behdad Esfahbod 2006-09-08 07:32:00 UTC
(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.
Comment 10 Adrian Johnson 2006-09-08 07:56:07 UTC
(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.

Comment 11 Behdad Esfahbod 2006-09-08 08:44:38 UTC
Testing.
Comment 12 Adrian Johnson 2006-09-08 08:52:46 UTC
(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);
-- 

Comment 13 Behdad Esfahbod 2006-09-08 09:02:52 UTC
The patch improves it, but doesn't quite fix it.  'w's are still clipped here.
Comment 14 Behdad Esfahbod 2006-09-08 09:10:14 UTC
I've added before/after shots here:  http://www.gnome.org/~behdad/tmp/

Mail and attachments seem to be broken.
Comment 15 Adrian Johnson 2006-09-09 07:49:36 UTC
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.
Comment 16 Dov Grobgeld 2006-09-09 11:16:02 UTC
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?
Comment 17 Behdad Esfahbod 2006-09-10 19:38:04 UTC
(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.
Comment 18 Behdad Esfahbod 2006-09-26 11:27:37 UTC
Adrian, are you going to commit the patch?
Comment 20 Kristian Høgsberg 2006-09-26 19:26:13 UTC
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.
Comment 21 Dov Grobgeld 2006-12-08 04:41:18 UTC
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
Comment 22 Dov Grobgeld 2007-01-03 10:10:28 UTC
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...


Comment 23 Behdad Esfahbod 2007-01-03 10:19:17 UTC
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.
Comment 24 Dov Grobgeld 2007-01-03 11:01:05 UTC
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

Comment 25 Carl Worth 2007-01-03 13:15:34 UTC
(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

Comment 26 Behdad Esfahbod 2007-01-03 14:18:42 UTC
paps is not generating TrueType subsets.  It does Type3 at best, but last time I
checked it was not even doing that.
Comment 27 Dov Grobgeld 2007-01-03 22:10:46 UTC
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.
Comment 28 Behdad Esfahbod 2007-01-03 22:19:43 UTC
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.
Comment 29 Behdad Esfahbod 2008-09-29 09:22:37 UTC
Dov, any progress has been made here?
Comment 30 Adrian Johnson 2008-10-11 02:13:42 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.