| Summary: | [FreeType] Do not special case the "sans" font family name | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Perez <aperez> | ||||
| Component: | Text | Assignee: | Adrian Perez <aperez> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | mmaxfield, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
Created attachment 468705 [details]
Screenshot of two browser, one of them with the “sans” matching removed
Here's a screenshot comparing how WebKitGTK behaves today (left), and
with the match for “sans” removed (right). The odd choice on the left
was because this particular system does not have a FontConfig “sans”
alias in the configuration, and FontConfig ends up picking a symbols
font (Font Awesome), which has these oddball latin characters.
(In reply to Adrian Perez from comment #1) > Created attachment 468705 [details] > Screenshot of two browser, one of them with the “sans” matching removed > > Here's a screenshot comparing how WebKitGTK behaves today (left), and > with the match for “sans” removed (right). The odd choice on the left > was because this particular system does not have a FontConfig “sans” > alias in the configuration, and FontConfig ends up picking a symbols > font (Font Awesome), which has these oddball latin characters. Of course if I make sure that there is a “sans” alias defined in the FontConfig configuration, that ends up being picked. I think in case somebody has an oddball configuration like the one I used for testing, having a serif font picked as fallback is still better than picking a symbols font. Pull request: https://github.com/WebKit/WebKit/pull/20776 Committed 271007@main (9479bf3bdea7): <https://commits.webkit.org/271007@main> Reviewed commits have been landed. Closing PR #20776 and removing active labels. |
In “Source/WebCore/platform/graphics/freetype/FontCacheFreeType.cpp” the is one instance where we are special-casing the “sans” font family name, which is NOT a CSS generic font family name, in the first line of the following function: static inline bool isCommonlyUsedGenericFamily(const String& familyNameString) { return equalLettersIgnoringASCIICase(familyNameString, "sans-serif"_s) || equalLettersIgnoringASCIICase(familyNameString, "serif"_s) || equalLettersIgnoringASCIICase(familyNameString, "monospace"_s) || equalLettersIgnoringASCIICase(familyNameString, "fantasy"_s) #if PLATFORM(GTK) || equalLettersIgnoringASCIICase(familyNameString, "-webkit-system-font"_s) || equalLettersIgnoringASCIICase(familyNameString, "-webkit-system-ui"_s) #endif || equalLettersIgnoringASCIICase(familyNameString, "cursive"_s); } Matching the “sans” name here skips a part of the CSS font fallback algorithm, which results in websites which use e.g. “font-family: sans” to end up picking an apparently semi-random choice of font depending on how FontConfig is configured. Given that a number of Linux distributions include font packages which have drop-in FontConfig configuration files which may define replacements and/or aliases for a family named “sans”, each user may see a slightly different outcome due to this bug. The solution is to do like the rest of the WebKit font implementations and not handle “sans” as a generic family name -- because it is not.