[Webkit-unassigned] [Bug 176351] [GTK] Bump freetype version to 2.8.0

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=176351

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |behdad at google.com,
                   |                            |clopez at igalia.com,
                   |                            |mcatanzaro at igalia.com,
                   |                            |mrobinson at webkit.org,
                   |                            |zan at falconsigh.net

--- Comment #1 from Carlos Garcia Campos <cgarcia at igalia.com> ---
I've been working on this and I've realized that after the 2.8 upgrade we have some failures that don't look correct. The problem is not new, though see bug #102374. That bug was closed because a patch was added for freetype 2.4.11, it was a cherry-pick of a freetype commit (http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=e0469372be3870a5ad60b2c4586e9c281357bd28), but that was reverted in freetype just a few revisions later (http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=87dc86d68c93c2b5b836501ece57583d1d6d1a2e), so when upgrading to 2.8 I decided not to include the patch. 

So, with 2.8 now we are getting:

ascent: 15.000000, descent: 4.000000, height: 18.000000

while with previous patched version we got:

ascent: 14.000000, descent: 3.000000, height: 17.000000

this means that now ascent + descent > height and we are getting a lineGap of -1.

I don't want to keep using a patch that has been reverted upstream. This patch is also the reason why we get different results in many layout tests when not using the internal jhbuild. Also, I don't know why, but I tried to backport the patch to 2.8 just to check what happened and I was still getting -1, so that's no longer a solution.

I'm not a fonts expert but the problem seems to be the rounding done by cairo when using hint metrics. When not using them what we get is:

ascent: 14.257812, descent: 3.460938, height: 18.398438

where ascent + descent <= height and we get a line gap of 0.679688

I think we have several options here:

a) Try to clamp the line gap to be 0 when we get a negative value
b) Create a temporary cairo font with hint metrics disable only to get the metrics (this is the patch proposed by Dominik in bug #102374).
c) Use freetype api directly to get the metrics instead of cairo.

I don't know if these are valid solutions or if there's a better one. Thoughts?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170905/57a267bb/attachment-0001.html>