Bug 4156

Created attachment 2942 [details]
a pangocairo test program (in python)

Created attachment 2943 [details]
pure cairo test case (incomplete)

OK, so the pure cairo test case I was able to come up with so far is this one. 
It doesn't trigger the bug.  However, it only uses the equivalent to pango's
_ink rect_ metrics, while the pangocairo test uses _logical rect_ metrics.

  I'm looking at pango/pango/pangocairo-fcfont.c, function
compute_glyph_extents(), where the pango metrics are computed.	It seems the
logical rect is computed using pango scaled font metrics:
[...]
      cairo_scaled_font_glyph_extents (scaled_font,
				       &cairo_glyph, 1, &extents);
[...]
      logical_rect->width = extents.x_advance * PANGO_SCALE;

  Could there be a bug in PDF's cairo_scaled_font_glyph_extents, I wonder?...

Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.

Created attachment 3007 [details]
C version of your  Pango test case

Converted the python to C (don't have Python 2.4 on this machine, so I can't
compile pygtk head)

The PNG and PDF output look pretty much identical to me. Then again, I'm
not testing testing with FreeSerif... it's a font that causes a *lot*
of problems for internationalization, by having broken characters in it
for complex scripts. Do you think you could test with the (shareware)
Code2000? (http://home.att.net/~jameskass/code2000_page.htm)

I already had Code2000 installed, it's a great font.  It does _not_ trigger the
bug.  But FreeMono does (actually FreeSerif doesn't seem to have that char and
pango happily replaces it with FreeMono, or so gucharmap seems to indicate).  I
can attach generated pdf and png, if it helps.  I can see that in the PDF, the
vertical bar is much further to the left side of the bounding box than in the
PNG file.

I have decided to try to remove these fonts.  Then my complex MathML renderer
outputs a perfect PDF file, for several test cases!  So, there is definitely
something wrong with these fonts.  It is most unfortunate that one of my "must
have" applications (tvtime) has a dependency on these fonts (ttf-freefont
package in ubuntu) :-(

Still, even if the fonts are broken, can I expect cairo/pango to workaround this
issue, or should I try to workaround it myself in the application layer?  I
could explicitly request Code2000 font, but the user may not have it, and still
have another font that provides the required glyph with good metrics, but if
FreeMono is first in the search path it will ruin everything.  If you have any
suggestion on how I could 'blacklist' this font from the application, I'm all
ears :)

PS: pygtk 2.7.x works fine on python >= 2.3.5, no need to have 2.4.

Hmm, the ways I know that the Free* fonts are broken shouldn't cause a problem
like this.

I think somebody with the fonts on their system would have to debug what's
going on. It could definitely be some sort of bug in the font embedding
code. One interesting thing might be to try the PS backend and see if the
bug occurs there.

(Python 2.3.4 is what I have here... need to upgrade this machine to FC4
or rawhide)

I'm also having the same problem with misplaced glyphs.  I'm not using Pango but
am directly loading a TTF into freetype and calling
cairo_ft_font_face_create_for_ft_face.  I should not it seems that glyphs are
only misplaced if I rotate the text.  If it isn't rotated then things seem to be
fine.
Unfortunately I don't have sample code or test cases.  I'll try and add them.

I tested the PS backend.  It is consistently as broken as the PDF one.  It is
actually broken in exactly the same way, as both outputs are identical.

I have found why my glyphs were being misplaced.  The extents reported back by
cairo are in device space and not user space.  This may affect how the pango
backend works I don't know (since I haven't used Pango).  

I think that this bug does not exist anymore, at this point in time, according
to my tests...