[iOS] Arabic letter Yeh is drawn in LastResort
authormmaxfield@apple.com <mmaxfield@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 11 Aug 2015 18:05:40 +0000 (18:05 +0000)
committermmaxfield@apple.com <mmaxfield@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 11 Aug 2015 18:05:40 +0000 (18:05 +0000)
commit06d50262b7d05a61a0980e5417ca1f2ead548f66
tree107a371affcc6c9fb3746073e93beb0290f9e820
parent46434740dbc507bc16aec7b03290a2ad95187b3a
[iOS] Arabic letter Yeh is drawn in LastResort
https://bugs.webkit.org/show_bug.cgi?id=147862
<rdar://problem/22202935>

Reviewed by Darin Adler.

Source/WebCore:

In order to perform font fallback, we must know which fonts support which characters. We
perform this check by asking each font to map a sequence of codepoints to glyphs, and
any glyphs which end up with a 0 value are unsupported by the font.

One of the mechanisms that we use to do this is to combine the code points into a string,
and tell Core Text to lay out the string. However, this is fundamentally a different
operation than the one we are trying to perform. Strings combine adjacent codepoints into
grapheme clusters, and CoreText operates on these. However, we are trying to gain
information regarding codepoints, not grapheme clusters.

Instead of taking this string-based approach, we should try harder to use Core Text
functions which operate on ordered collections of characters, rather than strings. In
particular, CTFontGetGlyphsForCharacters() and CTFontGetVerticalGlyphsForCharacters()
have the behavior we want where any unmapped characters end up with a 0 value glyph.

Previously, we were only using the result of those functions if they were successfully
able to map their entire input. However, given the fact that we can degrade gracefully
in the case of a partial mapping, we shouldn't need to bail completely to the
string-based approach should a partial mapping occur.

At some point we should delete the string-based approach entirely. However, this path
is still explicitly used for composite fonts. Fixing that use case is out of scope
for this patch.

Test: fast/text/arabic-glyph-cache-fill-combine.html

* platform/graphics/mac/GlyphPageMac.cpp:
(WebCore::GlyphPage::fill):

LayoutTests:

* fast/text/arabic-glyph-cache-fill-combine-expected.html: Added.
* fast/text/arabic-glyph-cache-fill-combine.html: Added.
* platform/mac/TestExpectations: Mark test as iOS-specific
* platform/gtk/TestExpectations: Mark test as iOS-specific
* platform/efl/TestExpectations: Mark test as iOS-specific
* platform/efl/TestExpectations: Mark test as iOS-specific

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@188263 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/fast/text/arabic-glyph-cache-fill-combine-expected.html [new file with mode: 0644]
LayoutTests/fast/text/arabic-glyph-cache-fill-combine.html [new file with mode: 0644]
LayoutTests/platform/efl/TestExpectations
LayoutTests/platform/gtk/TestExpectations
LayoutTests/platform/mac/TestExpectations
LayoutTests/platform/win/TestExpectations
Source/WebCore/ChangeLog
Source/WebCore/platform/graphics/mac/GlyphPageMac.cpp