Bug 244762 - Redesign the interaction between primary font selection and unicode-range
Summary: Redesign the interaction between primary font selection and unicode-range
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-09-03 13:35 PDT by Myles C. Maxfield
Modified: 2022-09-10 13:36 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Myles C. Maxfield 2022-09-03 13:35:55 PDT
For content like this:

```
@font-face {
    font-family: a;
    src: url("MyFont.ttf");
    unicode-range: some range;
}
@font-face {
    font-family: a;
    src: url("MyOtherFont.ttf");
    unicode-range: a distinct range that doesn't intersect the other font's range;
}
```

It's non-obvious which font should be considered the primary font for the purpose of inline layout (vertical height calculations). Right now we pick MyOtherFont.ttf just because it's last in content order, but that's wasteful because it's totally possible that none of the characters will actually be rendered with that font.

We should try to redesign this in a way that:
a) makes more intuitive sense
b) is consistent with other browsers
c) matches the spec (potentially by modifying the spec to match whatever this redesign yields)
Comment 1 Myles C. Maxfield 2022-09-03 13:37:04 PDT
(In particular, consider the case where neither "some range" nor "a distinct range that doesn't intersect the other font's range" contain the space character.)
Comment 2 Myles C. Maxfield 2022-09-03 13:39:10 PDT
(This is from https://github.com/WebKit/WebKit/pull/3988)
Comment 3 Radar WebKit Bug Importer 2022-09-10 13:36:16 PDT
<rdar://problem/99783313>