Bug 232293 - The space glyph in the Filicudi font is not substituted by shaping in the complex text codepath, thereby breaking the visual effect of the font
Summary: The space glyph in the Filicudi font is not substituted by shaping in the com...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Myles C. Maxfield
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-10-25 19:47 PDT by Myles C. Maxfield
Modified: 2021-10-28 17:22 PDT (History)
5 users (show)

See Also:


Attachments
Needs test (1.60 KB, patch)
2021-10-25 19:47 PDT, Myles C. Maxfield
no flags Details | Formatted Diff | Diff
Patch (14.48 KB, patch)
2021-10-28 12:28 PDT, Myles C. Maxfield
no flags Details | Formatted Diff | Diff
Patch (17.04 KB, patch)
2021-10-28 15:11 PDT, Myles C. Maxfield
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Myles C. Maxfield 2021-10-25 19:47:20 PDT
[Cocoa] Don't clobber the space character's glyph after shaping in the complex text codepath
Comment 1 Myles C. Maxfield 2021-10-25 19:47:43 PDT
Created attachment 442455 [details]
Needs test
Comment 2 mitz 2021-10-25 23:30:39 PDT
(In reply to Myles C. Maxfield from comment #1)
> Created attachment 442455 [details]
> Needs test

Very curious to see what this changes!
Comment 3 Myles C. Maxfield 2021-10-26 01:46:52 PDT
(In reply to mitz from comment #2)
> (In reply to Myles C. Maxfield from comment #1)
> > Created attachment 442455 [details]
> > Needs test
> 
> Very curious to see what this changes!

https://fonts.adobe.com/fonts/tipoteca-series#fonts-section
Comment 4 Myles C. Maxfield 2021-10-28 12:28:18 PDT
Created attachment 442730 [details]
Patch
Comment 5 Darin Adler 2021-10-28 12:52:21 PDT
Comment on attachment 442730 [details]
Patch

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

> Source/WebCore/platform/graphics/ComplexTextController.cpp:715
>              FloatSize advance = treatAsSpace ? FloatSize(spaceWidth, advances[i].height()) : advances[i];

Why is it safe to use spaceWidth with a non-space glyph?
Comment 6 Myles C. Maxfield 2021-10-28 14:49:56 PDT
Comment on attachment 442730 [details]
Patch

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

>> Source/WebCore/platform/graphics/ComplexTextController.cpp:715
>>              FloatSize advance = treatAsSpace ? FloatSize(spaceWidth, advances[i].height()) : advances[i];
> 
> Why is it safe to use spaceWidth with a non-space glyph?

We have to set the spaceWidth because different parts of webkit measure text in differently-sized chunks. For example, computing the preferred widths measures word-by-word, but painting - which requires measuring - measures the entire run. In order to have these different strategies measure consistently, we have to clobber the widths of all the space characters to set them consistently. These space width adjustments are small - they're usually due to slight kerning of characters like "T" around a space.

This bug itself, though, is saying we can't clobber the space glyph. So it seems we find ourselves in a situation where we have to clobber the width, but we can't clobber the glyph. It seems a bit scary, but I think in practice it will actually be an improvement, because:
1) These glyphs we're dealing with here are almost always invisible, so clobbering / not clobbering won't have much effect
2) Because the width adjustments are usually small, the chance for a mismatch causing broken rendering is also small

Long term, though, we'll stop clobbering space widths, too, because IFC will help us be more deliberate about the chunks we measure text in. And, I'm hoping to migrate to an architecture where we don't even have to measure text multiple times during layout in the first place (if it's possible without a memory regression). So, I think this patch is both A) an improvement upon what we're shipping today, and B) a step in the right future direction.
Comment 7 Myles C. Maxfield 2021-10-28 14:58:42 PDT
Comment on attachment 442730 [details]
Patch

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

>>> Source/WebCore/platform/graphics/ComplexTextController.cpp:715
>>>              FloatSize advance = treatAsSpace ? FloatSize(spaceWidth, advances[i].height()) : advances[i];
>> 
>> Why is it safe to use spaceWidth with a non-space glyph?
> 
> We have to set the spaceWidth because different parts of webkit measure text in differently-sized chunks. For example, computing the preferred widths measures word-by-word, but painting - which requires measuring - measures the entire run. In order to have these different strategies measure consistently, we have to clobber the widths of all the space characters to set them consistently. These space width adjustments are small - they're usually due to slight kerning of characters like "T" around a space.
> 
> This bug itself, though, is saying we can't clobber the space glyph. So it seems we find ourselves in a situation where we have to clobber the width, but we can't clobber the glyph. It seems a bit scary, but I think in practice it will actually be an improvement, because:
> 1) These glyphs we're dealing with here are almost always invisible, so clobbering / not clobbering won't have much effect
> 2) Because the width adjustments are usually small, the chance for a mismatch causing broken rendering is also small
> 
> Long term, though, we'll stop clobbering space widths, too, because IFC will help us be more deliberate about the chunks we measure text in. And, I'm hoping to migrate to an architecture where we don't even have to measure text multiple times during layout in the first place (if it's possible without a memory regression). So, I think this patch is both A) an improvement upon what we're shipping today, and B) a step in the right future direction.

I guess I should probably say this stuff in the ChangeLog. And I should rename the bug so the title is about the problem, not about the solution.
Comment 8 Myles C. Maxfield 2021-10-28 15:11:42 PDT
Created attachment 442748 [details]
Patch
Comment 9 EWS 2021-10-28 17:21:11 PDT
Committed r285009 (243655@main): <https://commits.webkit.org/243655@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 442748 [details].
Comment 10 Radar WebKit Bug Importer 2021-10-28 17:22:44 PDT
<rdar://problem/84786325>