Font-family name matching requires full Unicode case comparison

[litherum]

https://drafts.csswg.org/css-fonts-4/#localized-name-matching

This is the only place in WebKit that requires a full Unicode case matching. We have intentionally not implemented this because it’s non-performant. Instead, we just do ASCII case folding. It would be good if we could improve the performance of all implementations by specifying in the spec to use only ASCII case folding. Font lookups are very common in every page load, so performance here is very important. Also, we haven’t had web compatibility bugs due to not performing full Unicode case matching.

http://userguide.icu-project.org/transforms/casemappings says that “there is a flag for whether to apply special mappings for use with Turkic (Turkish/Azerbaijani) text data“ so if we’re going to define that it really requires full Unicode case matching, we’ll have to define how to set this flag.

[tabatkins]

So ASCII case-insensitive, otherwise codepoint-wise comparison?

[litherum]

Cc @kojiishi @drott @jfkthame

[litherum]

@tabatkins Yes

[jfkthame]

I don't think performance should actually be an issue here, given that the spec says "the algorithm [Default Caseless Matching] must be applied without normalizing the strings involved and without applying any language-specific tailorings". So issues like the Turkish i/ı don't arise.

[drott]

This is the only place in WebKit that requires a full Unicode case matching.

Can you specify in more detail what do you mean by full Unicode case matching here? Do you mean case-sensitive matching? I understand the current spec to mean: Perform "Default Caseless Matching" from https://www.unicode.org/versions/Unicode9.0.0/ch03.pdf section 3.13, with emphasis on doing that without normalization and without language specifc tailorings. This would be only the comparison mentioned in the Unicode spec as D144:

D144 A string X is a caseless match for a string Y if and only if:
toCasefold(X) = toCasefold(Y)

Implementation wise, I believe this would be http://icu-project.org/apiref/icu4c/classicu_1_1UnicodeString.html#a0924f873180947aab38b7380da638533 with U_FOLD_CASE_EXCLUDE_SPECIAL_I.

I think the spec already describes that this flag should be set accordingly, as tailorings are excluded from the matching algorithm.

What performance benefits do you see from only performing casefolding for the ASCII range?

[litherum]

Right, implementing this would require calling into ICU for the string comparison, rather than a tight loop with some bit manipulation. We haven’t done performance analysis to know what the performance regression would be if we adhered to the spec here; however, we expect it to be significant. WebKit has never adhered to this part of the spec.

[css-meeting-bot]

The CSS Working Group just discussed font-matching and unicode, and agreed to the following:

• RESOLVED: Use ascii-case folding

The full IRC log of that discussion

<emilio_> topic: font-matching and unicode
<emilio_> github: https://github.com//issues/3675
<astearns> github: https://github.com//issues/3675
<emilio_> myles__: Spec says that in order to match font-family names full unicode case folding needs to be performed
<emilio_> myles__: so you need to run the names to complicated ICU routines
<emilio_> myles__: We just fold ascii chars in WebKit, for performance reasons
<emilio_> myles__: we never perform unicode case folding in WebKit
<emilio_> fantasai: When you search on a page?
<emilio_> myles__: that particular API is a different one, but we do use unicode
<emilio_> myles__: It should use compatibility decomposition and caseless matching
<emilio_> s/myles__/fantasai
<emilio_> myles__: ascii case folding is fast
<emilio_> myles__: I haven't done any measurement but if we used the unicode case comparison it'd likely be a perf regression because font lookups are hot
<emilio_> myles__: wanted to relax this restriction
<emilio_> heycam: why not require the ascii-case folding?
<emilio_> myles__: that's fine too
<emilio_> heycam: I don't think there's many situations when you have non-ascii names?
<emilio_> myles__: fonts have many names in many languages, in addition to an ascii name, generally
<emilio_> florian[m]: isn't common to have a case-mismatched cyrillic name? Is it not a compat issue?
<emilio_> myles__: it's not
<emilio_> myles__: proposed resolution is that font-family lookups should use ascii-case-insensitive matching
<emilio_> dbaron: what do other implementations do?
<emilio_> myles__: probably matches chrome
<emilio_> eae: it does
<fantasai> fantasai: I'd like to check with jfkthame
<fantasai> emilio_: I can check what Firefox does, hang on
<emilio_> emilio_: We do whatever nsCaseInsensitiveStringComparator does
<emilio_> dbaron: that's ascii
<emilio_> RESOLVED: Use ascii-case folding