[Webkit-unassigned] [Bug 77437] freetype port: font fallback mechanism can try harder

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 6 03:17:35 PST 2012


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





--- Comment #6 from Martin Jackson <mjackson220.list at gmail.com>  2012-03-06 03:17:35 PST ---
(In reply to comment #5)

Hi Martin,

Thanks for getting back to me on this.

> I appreciate this patch, but I don't quite understand it. How does FontCache::getSimilarFontPlatformData interact with the changes you made in the platform-independent code. 

The patch was created in response to a bug that we had internally: Arial was requested by a web page, but since we didn't have this font in$talled, we ended up getting a serif font which was dissimilar to Arial (while we had perfectly good open alternatives installed, of which fontconfig was aware).

If none of the font families in the font fallback list, as defined in the web page, could be found, getSimilarFontPlatformData is called. Previously, webkit just give up at this point and fell through to getLastResortFallbackFont, which just substitutes 'serif' (in the freetype port at least)

I added an extra flag, m_exactFamily, to the FontDescription which indicates whether the system is allowed to substitute what it considers to be 'similar' font families for what was requested, or whether *only* what was requested will be accepted.

In general, m_exactFamily == true (i.e. we want the *exact* font family only). Then the CSS font family fallback list can be iterated (http://www.w3.org/TR/css3-fonts/#font-matching-algorithm) correctly. In getSimilarFontPlatformData, the system has failed to find any of the fonts that were requested, and so relaxes the exact matching condition (i.e. m_exactFamily -> 0) and then tries to use fontconfig to locate an appropriate replacement font for the first choice of font family as specified in the web page.

> 
> Is this change testable. For GTK+ we have a very particular fontconfig environment that we've set up for testing changes like this. Is there a page that this change affects?

The change is of course testable - however because it is highly installation dependent, I didn't really know what to do. I'm not familiar with how you go about this in the GTK+ port - if you can give me some pointers on how to reproduce your test setup, I'll do my best to provide a sensible test case.

Regards

Martin Jackson

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list