[Webkit-unassigned] [Bug 247987] Regression: "font-optical-sizing: auto" has no effect in Safari 16 on macOS Ventura & iOS 16

[bugzilla-daemon at webkit.org]

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

--- Comment #11 from Myles C. Maxfield <mmaxfield at apple.com> ---
Oh, thanks for all the links!

I totally forgot about this bug until today; I'll see if I can fix it this week.

Some background:

This is caused by a Core Text behavior change. Previously, when you create a font, by default, the font will have optical sizing enabled. Now, it will only have optical sizing enabled if there are no named instances that set opsz to a non-default value. We view this Core Text change as a behavior improvement and a progression.

For WebKit, though, we want font-optical-sizing:auto to enable optical sizing, regardless of the details of the named instances.

When creating a font, right now WebKit:
1. Creates a CTFontDescriptor
2. Creates a font
3. Inspects the font's attributes (e.g. see which features it supports, which variation axes it supports)
4. If the font is already set up appropriately, we're done, just use it.
5. Otherwise, create a delta CTFontDescriptor, and
6. Create a copy of the font with the delta CTFontDescriptor

In step 4, WebKit says "If font-optical-sizing:auto is specified, we can use the existing font, because we expect Core Text to apply optical sizing" but now that Core Text won't always apply optical sizing, that logic in WebKit is erroneous.

We probably shouldn't investigate the details of the font's named instances to make a fine-grained filter for which fonts should execute steps 5 and 6. Instead, we should be explicit and say "if CSS tells us to apply optical sizing, let's explicitly make sure optical sizing is enabled in Core Text"

However, we *probably* can't just say "yolo every font has to execute steps 5 and 6" because of performance. (Though this is worth testing.)

So, I think the fix here is to just delete steps 5 and 6 wholesale, for all fonts, and make the original font we create in step 2 have all the necessary attributes. That might actually cause a performance *progression*!

There are 2 reasons steps 5 and 6 existed in the first place:
1. To work around Core Text bugs from years and years ago, which have since been fixed in all OSes that WebKit ships on
2. So we know whether the variable font is a GX font or not, which affects the scaling of the font-weight and other property values: OT 1.9 variable fonts use 100-900 for weight, whereas GX fonts use roughly 0.0 to 2.0 for weight (see https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6fvar.html)

(1) has an obvious solution, but I'm a little less sure about (2). I should check whether or not the other browsers do any scaling for GX fonts, or whether there's another solution here.

But, either way, deleting steps 5 and 6 is a not-insubstantial refactoring effort. It will probably be a few day's full-time work.

-- 
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/20230108/5f79a637/attachment.htm>