GNOME Bugzilla – Bug 686709
Some font glyphs are clipped
Last modified: 2016-12-08 11:45:42 UTC
Created attachment 227069 [details] Patch for examples/cogl-crate.c which makes it exhibit the bug Using the "VL Gothic" font with a bold weight glyphs get their tops clipped off. I guess this could be a font bug but gtk+ doesn't do this with the same font parameters.
The font can be obtained at http://sourceforge.jp/projects/vlgothic/releases/56952 .
Created attachment 227070 [details] JS test case JS test case that clearly shows the bug with 2 windows one using gtk+ and the other using clutter.
*** Bug 693888 has been marked as a duplicate of this bug. ***
*** Bug 694520 has been marked as a duplicate of this bug. ***
Created attachment 251503 [details] [review] cogl-pango: Consider glyph descent when calculating boundary I looked at this a bit more closely, and found that the clipped height is exactly the same as the descent of the glyph. After adjusting it in the glyph cache, the problem seems to be fixed.
The problem still exists in Fedora 20 Alpha RC3, cogl-1.15.10-2.fc20.x86_64. Maybe Ueno San’s patch is not integrated yet?
Created attachment 255154 [details] glyphs-clipped-in-screen-locker-f20.png Screenshot showing the problem in Fedora 20 Alpha RC3.
Thanks for the patch. I'm not too sure about landing it because from my understanding of the Pango documentation the ink rect that we are using should already cover the width and height of the drawn area of the glyph. The reasoning for adding the descent in the git message doesn't sound very confident that this is the right thing to do so I'd like to be more sure that it isn't just coincidence that it fixes the problem. I guess the next step would be to work out what GTK is doing different so that it doesn't have the problem. If I remember correctly GTK has a similar glyph cache.
Created attachment 255173 [details] Screenshot of the glyph images that are generated I tweaked Cogl to dump the images that it generates for each glyph before uploading it into the texture. It looks like the size of the image is actually big enough if it would just draw it slightly lower. Maybe that implies we are using the y offset incorrectly. However it looks like the Pango ink rect comes directly from the y_bearing returned by cairo_scaled_font_glyph_extents and the documentation for that says: “the vertical distance from the origin to the topmost part of the glyphs as drawn. Positive only if the glyphs lie completely below the origin; will usually be negative.” So it seems like it is the value we want. Maybe we can get one of the Pango or Cairo developers to comment.
Neil, can you give me instructions to replicate those images?
I checked the code. Looks fine to me. Need to run it and inspect returned values.
Created attachment 255284 [details] [review] dump glyph images and set font in cogl-crate If you apply this patch to Cogl and the run the cogl-crate example in the examples directory it will dump the glyph images into your home directory as glyph-0.png, glyph-1.png etc. You can also see the bug in the text on top of the crate. Thanks for looking into it.
Reproduced. Digging in.
I can reproduce the bug with pango-view: $ pango-view --font 'VL Gothic Bold 300' --text 6 --annotate=1 Looks to me like a bug in FreeType's emboldening code or something. Checking out.
I just confirmed that this happens with any emboldened font.
Sent patch to freetype-devel. diff --git a/src/base/ftsynth.c b/src/base/ftsynth.c index 241d37f..1d01247 100644 --- a/src/base/ftsynth.c +++ b/src/base/ftsynth.c @@ -143,6 +143,7 @@ slot->metrics.height += ystr; slot->metrics.horiAdvance += xstr; slot->metrics.vertAdvance += ystr; + slot->metrics.horiBearingY+= ystr; /* XXX: 16-bit overflow case must be excluded before here */ if ( slot->format == FT_GLYPH_FORMAT_BITMAP )