Bug 211005 – Update svg/batik/text/xmlSpace.svg to yield consistent text metrics

• Component: New Bugs
• Status: RESOLVED FIXED

[Myles C. Maxfield]

Update svg/batik/text/xmlSpace.svg to yield consistent text metrics

[Myles C. Maxfield]

Created attachment 397530 [details]
Patch

[Myles C. Maxfield]

<rdar://problem/62312187>

[Myles C. Maxfield]

Created attachment 397531 [details]
Patch

[Darin Adler]

Comment on attachment 397531 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=397531&action=review

> LayoutTests/ChangeLog:12
> +        The test is rendering a bunch of characters without using a specified font.
> +        This means that Core Text is picking an arbitrary font. However, the
> +        -expected.txt file is measuring exact pixel widths. The solution is to just
> +        give the test an explicit fallback font.

Good fix for the test, I guess.

But is it compatible web behavior to let "Core Text" pick an *arbitrary* font?

[Myles C. Maxfield]

Comment on attachment 397531 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=397531&action=review

>> LayoutTests/ChangeLog:12
>> +        give the test an explicit fallback font.
> 
> Good fix for the test, I guess.
> 
> But is it compatible web behavior to let "Core Text" pick an *arbitrary* font?

Once we fall off the end of the font-family list, we have no more signal. We pass the first font in the font-family list to Core Text and say "please find some font on the system which looks like this one but also supports this character." Because we have no additional signal, there's not really anything else we can do here.

I don't think we've gotten bugs about this, because if an author wants to use a particular font, they can just add an entry into the font-family list. The set of installed fonts is different between operating systems (indeed, different versions of the same operating system), so I don't think there's really any consistent mapping we can do here (once we fall off the end of the font-family list).

https://developer.apple.com/documentation/ says the official name is "Core Text."

[Darin Adler]

Yes, I’m just saying that it’s WebKit’s responsibility to make sure the right font is chosen, and we can’t just blame the underlying system.

Why is it good for web compatibility to "pass the first font in the font-family list to Core Text and say 'please find some font on the system which looks like this one but also supports this character?'"

Is there a better strategy?

[Myles C. Maxfield]

(In reply to Darin Adler from comment #6)
> Yes, I’m just saying that it’s WebKit’s responsibility to make sure the
> right font is chosen, and we can’t just blame the underlying system.
> 
> Why is it good for web compatibility to "pass the first font in the
> font-family list to Core Text and say 'please find some font on the system
> which looks like this one but also supports this character?'"
> 
> Is there a better strategy?

Ah, I see what you're saying. I think the question to investigate is "what are the pros/cons of the various options?"

Option 1: Use the Core Text function we're using today. This has two benefits - A) the fallback sequence matches the rest of the system (for a fuzzy definition of "matches") and B) we leverage the expertise of our fonts team to select typographically high-quality fonts. The downsides are A) that the platform can and will change behavior, causing bugs like these, and B) The fallback logic might not match other browsers.

Option 2: Reverse engineer the dominant browser, and copy their fallback behavior. This has the benefit that the web will appear to change less when a user switches browser, but it will appear to change more when the user switches apps. I believe most users switch apps more often than they switch browsers.

Option 3: Use a bespoke set of fallback fonts, just for the web, that we believe are typographically high-quality. This sacrifices consistency with both apps and other browsers. In addition, the Core Text fallbacks are already quite typographically high-quality, as they have been crafted by Apple's team of experts.

Option 4: Maybe something I haven't thought of yet?

Given the number of bug reports we've gotten in this area, I don't think Option 2 has a huge amount value. It seems like the best cost/benefit tradeoff is if we go with Option 1.

[Myles C. Maxfield]

Created attachment 397540 [details]
Patch for committing

[Alexey Proskuryakov]

What are the scenarios where consistency with other apps is observable by the user? I can think of copy/paste, but nothing else. The user doesn’t know which fonts were specified in markup.

[Myles C. Maxfield]

(In reply to Alexey Proskuryakov from comment #9)
> What are the scenarios where consistency with other apps is observable by
> the user? I can think of copy/paste, but nothing else. The user doesn’t know
> which fonts were specified in markup.

Any user-generated text will trigger this. Users don’t know which fonts were selected in native apps, but they do know the visual traits of those fonts (serif, sans-serif, etc.) this is the kind of signal Core Text uses when finding fallback fonts.

So the scenario is “a user types a character from an unexpected language into a text field where the surrounding text looks a certain way.”

[Alexey Proskuryakov]

Are you saying that inconsistency with native apps would be that serif/sans-serif traits for fallback would be different from primary text? That's not inconsistency, it's an outright bug.

[Myles C. Maxfield]

Created attachment 398267 [details]
Patch for committing

[Myles C. Maxfield]

Created attachment 398276 [details]
Patch for committing

[EWS]

Committed r261154: <https://trac.webkit.org/changeset/261154>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 398276 [details].