Bug 265182 – [FreeType] Do not special case the "sans" font family name

• Component: Text
• Status: RESOLVED FIXED

[Adrian Perez]

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.

[Adrian Perez]

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.

[Adrian Perez]

(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.

[Adrian Perez]

Pull request: https://github.com/WebKit/WebKit/pull/20776

[EWS]

Committed 271007@main (9479bf3bdea7): <https://commits.webkit.org/271007@main>

Reviewed commits have been landed. Closing PR #20776 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/118680927>