[Webkit-unassigned] [Bug 265182] New: [FreeType] Do not special case the "sans" font family name

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 21 00:48:33 PST 2023


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

            Bug ID: 265182
           Summary: [FreeType] Do not special case the "sans" font family
                    name
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Text
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aperez at igalia.com
                CC: mmaxfield at apple.com

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.

-- 
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/20231121/3544144c/attachment.htm>


More information about the webkit-unassigned mailing list