Title: [222090] trunk/Source/WebCore
- Revision
- 222090
- Author
- [email protected]
- Date
- 2017-09-15 08:37:02 -0700 (Fri, 15 Sep 2017)
Log Message
[Harfbuzz] Material icons not rendered correctly when using the web font
https://bugs.webkit.org/show_bug.cgi?id=176995
Reviewed by Michael Catanzaro.
Only a few of them are correctly rendered and some others are wrong. We only render correctly the ones that
don't have an underscore in their name (or that start with a number like 3d_rotation). In the cases where the
name before the underscore is also an icon, we render that icon instead, that's why some of them are wrong. This
is happening because the underscore is causing the HarfbuffShaper to split the text in 3 runs, one for the word
before the underscore, another one for the underscore and another for the word after the underscore. So, we
end up trying to shape the 3 runs independently and we fail when the icon doesn't exist, or when it exists but
it's not the one we are looking for. The cause of this is that the underscore has a different script (Common)
than the rest of characters (Latin) which is a condition in HarfbuffShaper to create a different run. The
unicode spec says that characters with Common script should be handled differently, but we are just ignoring
it. The spec proposes to use an heuristic based on simply inheriting the script of the previous character, which
should work in most of the cases. We could take a more conservative approach and do that only if both characters
are ASCII. We should also consider handling other cases mentioned by the spec like brackets and quotation marks,
but that belongs to a different bug/commit.
* platform/graphics/harfbuzz/HarfBuzzShaper.cpp:
(WebCore::scriptsAreCompatibleForCharacters): Helper function to check if the current and previous scripts are
compatible,
(WebCore::HarfBuzzShaper::collectHarfBuzzRuns): Use scriptsAreCompatibleForCharacters() to decided whether to
finish the current run or not. In case of Common script, inherit also the script from the previous character.
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (222089 => 222090)
--- trunk/Source/WebCore/ChangeLog 2017-09-15 14:50:23 UTC (rev 222089)
+++ trunk/Source/WebCore/ChangeLog 2017-09-15 15:37:02 UTC (rev 222090)
@@ -1,5 +1,32 @@
2017-09-15 Carlos Garcia Campos <[email protected]>
+ [Harfbuzz] Material icons not rendered correctly when using the web font
+ https://bugs.webkit.org/show_bug.cgi?id=176995
+
+ Reviewed by Michael Catanzaro.
+
+ Only a few of them are correctly rendered and some others are wrong. We only render correctly the ones that
+ don't have an underscore in their name (or that start with a number like 3d_rotation). In the cases where the
+ name before the underscore is also an icon, we render that icon instead, that's why some of them are wrong. This
+ is happening because the underscore is causing the HarfbuffShaper to split the text in 3 runs, one for the word
+ before the underscore, another one for the underscore and another for the word after the underscore. So, we
+ end up trying to shape the 3 runs independently and we fail when the icon doesn't exist, or when it exists but
+ it's not the one we are looking for. The cause of this is that the underscore has a different script (Common)
+ than the rest of characters (Latin) which is a condition in HarfbuffShaper to create a different run. The
+ unicode spec says that characters with Common script should be handled differently, but we are just ignoring
+ it. The spec proposes to use an heuristic based on simply inheriting the script of the previous character, which
+ should work in most of the cases. We could take a more conservative approach and do that only if both characters
+ are ASCII. We should also consider handling other cases mentioned by the spec like brackets and quotation marks,
+ but that belongs to a different bug/commit.
+
+ * platform/graphics/harfbuzz/HarfBuzzShaper.cpp:
+ (WebCore::scriptsAreCompatibleForCharacters): Helper function to check if the current and previous scripts are
+ compatible,
+ (WebCore::HarfBuzzShaper::collectHarfBuzzRuns): Use scriptsAreCompatibleForCharacters() to decided whether to
+ finish the current run or not. In case of Common script, inherit also the script from the previous character.
+
+2017-09-15 Carlos Garcia Campos <[email protected]>
+
[Harfbuzz] Fix incorrect font rendering when selecting texts in pages which specifies text-rendering: optimizeLegibility
https://bugs.webkit.org/show_bug.cgi?id=148220
Modified: trunk/Source/WebCore/platform/graphics/harfbuzz/HarfBuzzShaper.cpp (222089 => 222090)
--- trunk/Source/WebCore/platform/graphics/harfbuzz/HarfBuzzShaper.cpp 2017-09-15 14:50:23 UTC (rev 222089)
+++ trunk/Source/WebCore/platform/graphics/harfbuzz/HarfBuzzShaper.cpp 2017-09-15 15:37:02 UTC (rev 222090)
@@ -359,6 +359,33 @@
return point + m_startOffset;
}
+static bool scriptsAreCompatibleForCharacters(UScriptCode script, UScriptCode previousScript, UChar32 character, UChar32 previousCharacter)
+{
+ if (script == previousScript)
+ return true;
+
+ if (script == USCRIPT_INHERITED || previousScript == USCRIPT_COMMON)
+ return true;
+
+ if (script == USCRIPT_COMMON) {
+ // ยง5.1 Handling Characters with the Common Script Property.
+ // Programs must resolve any of the special Script property values, such as Common,
+ // based on the context of the surrounding characters. A simple heuristic uses the
+ // script of the preceding character, which works well in many cases.
+ // http://www.unicode.org/reports/tr24/#Common.
+ //
+ // FIXME: cover all other cases mentioned in the spec (ie. brackets or quotation marks).
+ // https://bugs.webkit.org/show_bug.cgi?id=177003.
+ //
+ // We use a slightly more conservative heuristic than the one proposed in the spec,
+ // using the script of the previous character only if both are ASCII.
+ if (isASCII(character) && isASCII(previousCharacter))
+ return true;
+ }
+
+ return uscript_hasScript(character, previousScript);
+}
+
bool HarfBuzzShaper::collectHarfBuzzRuns()
{
const UChar* normalizedBufferEnd = m_normalizedBuffer.get() + m_normalizedBufferLength;
@@ -381,6 +408,7 @@
if (!currentFontData)
currentFontData = &m_font->primaryFont();
UScriptCode currentScript = nextScript;
+ UChar32 previousCharacter = character;
for (iterator.advance(clusterLength); iterator.consume(character, clusterLength); iterator.advance(clusterLength)) {
if (FontCascade::treatAsZeroWidthSpace(character))
@@ -410,11 +438,18 @@
nextScript = uscript_getScript(character, &errorCode);
if (U_FAILURE(errorCode))
return false;
- if ((nextFontData != currentFontData) || ((currentScript != nextScript) && (nextScript != USCRIPT_INHERITED) && (!uscript_hasScript(character, currentScript))))
+
+ if (nextFontData != currentFontData)
break;
- if (nextScript == USCRIPT_INHERITED)
+
+ if (!scriptsAreCompatibleForCharacters(nextScript, currentScript, character, previousCharacter))
+ break;
+
+ if (nextScript == USCRIPT_INHERITED || nextScript == USCRIPT_COMMON)
nextScript = currentScript;
+
currentCharacterPosition = iterator.characters();
+ previousCharacter = character;
}
unsigned numCharactersOfCurrentRun = iterator.currentIndex() - startIndexOfCurrentRun;
hb_script_t script = hb_icu_script_to_script(currentScript);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
