Bug 199912 – [iOS] Fast and complex text codepaths disagree about how to lay out bopomofo with tone marks

• Component: New Bugs
• Status: RESOLVED FIXED

[Myles C. Maxfield]

[iOS] Fast and complex text codepaths disagree about how to lay out bopomofo with tone marks

[Myles C. Maxfield]

Created attachment 374401 [details]
Patch

[Myles C. Maxfield]

<rdar://problem/52182454>

[Myles C. Maxfield]

Created attachment 374402 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 374402 [details]
Patch

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

> Source/WebCore/ChangeLog:10
> +        This is because CoreText has special composition rules for CJK languages, which we don't have in our simple
> +        text codepath. Rather than implementing the composition rules in WebKit, we can simply disable them in

Do we have them in our complex text codepath? Should we instead flip to that codepath when necessary?

[Myles C. Maxfield]

Comment on attachment 374402 [details]
Patch

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

>> Source/WebCore/ChangeLog:10
>> +        text codepath. Rather than implementing the composition rules in WebKit, we can simply disable them in
> 
> Do we have them in our complex text codepath? Should we instead flip to that codepath when necessary?

In our complex text codepath, CoreText does/would take care of it for us. It doesn't require any additional code in WebKit's complex text codepath. Instead, it would require additional code in WebKit's simple text codepath to match what the complex path does.

We can't flip to the complex text codepath for all CJK languages; that would be a huge performance regression.

[Myles C. Maxfield]

Comment on attachment 374402 [details]
Patch

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

>>> Source/WebCore/ChangeLog:10
>>> +        text codepath. Rather than implementing the composition rules in WebKit, we can simply disable them in
>> 
>> Do we have them in our complex text codepath? Should we instead flip to that codepath when necessary?
> 
> In our complex text codepath, CoreText does/would take care of it for us. It doesn't require any additional code in WebKit's complex text codepath. Instead, it would require additional code in WebKit's simple text codepath to match what the complex path does.
> 
> We can't flip to the complex text codepath for all CJK languages; that would be a huge performance regression.

In the longer term, we should implement support in our fast text codepath, and flip the CoreText support back on. https://bugs.webkit.org/show_bug.cgi?id=199913

[EWS Watchlist]

Comment on attachment 374402 [details]
Patch

Attachment 374402 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/12767807

New failing tests:
css3/font-feature-font-face-local.html
editing/mac/selection/word-thai.html
svg/custom/glyph-selection-arabic-forms.svg

[EWS Watchlist]

Created attachment 374405 [details]
Archive of layout-test-results from ews101 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 374402 [details]
Patch

Attachment 374402 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/12767822

New failing tests:
css3/font-feature-font-face-local.html
editing/mac/selection/word-thai.html
svg/custom/glyph-selection-arabic-forms.svg

[EWS Watchlist]

Created attachment 374406 [details]
Archive of layout-test-results from ews105 for mac-highsierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105  Port: mac-highsierra-wk2  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 374402 [details]
Patch

Attachment 374402 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/12767887

New failing tests:
legacy-animation-engine/fast/text/crash-complex-text-surrogate.html
css3/font-feature-font-face-local.html
fast/text/crash-complex-text-surrogate.html
svg/custom/glyph-selection-arabic-forms.svg

[EWS Watchlist]

Created attachment 374415 [details]
Archive of layout-test-results from ews123 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews123  Port: ios-simulator-wk2  Platform: Mac OS X 10.14.5

[EWS Watchlist]

Comment on attachment 374402 [details]
Patch

Attachment 374402 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/12767948

New failing tests:
storage/indexeddb/pending-version-change-on-exit-private.html
css3/font-feature-font-face-local.html
svg/custom/glyph-selection-arabic-forms.svg
editing/mac/selection/word-thai.html

[EWS Watchlist]

Created attachment 374416 [details]
Archive of layout-test-results from ews115 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[Myles C. Maxfield]

The test failures don't occur on macOS Catalina nor iOS 13 😢

[Myles C. Maxfield]

Created attachment 374437 [details]
Patch for committing

[Myles C. Maxfield]

Created attachment 374489 [details]
Patch for committing

[WebKit Commit Bot]

Comment on attachment 374489 [details]
Patch for committing

Clearing flags on attachment: 374489

Committed r247674: <https://trac.webkit.org/changeset/247674>