Title: [188569] trunk/Source/WebCore/ChangeLog
- Revision
- 188569
- Author
- mmaxfi...@apple.com
- Date
- 2015-08-17 19:44:14 -0700 (Mon, 17 Aug 2015)
Log Message
Follow up patch after r188566
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (188568 => 188569)
--- trunk/Source/WebCore/ChangeLog 2015-08-18 02:31:05 UTC (rev 188568)
+++ trunk/Source/WebCore/ChangeLog 2015-08-18 02:44:14 UTC (rev 188569)
@@ -22,15 +22,7 @@
Reviewed by Dan Bernstein.
- WebKit maintains a cache of code point to glyph mapping for a particular font. One of
- the ways WebKit populates this cache is to create a string holding consecutive code
- points, create a CTLineRef from the string, and use CTRunGetGlyphs() with
- CTRunGetStringIndices() to map from the code points to the glyphs. This approach is
- fundamentally incorrect, as it will combine consecutive code points together in the
- string if possible to produce a glyph.
-
- The only way WebKit will ever trigger this code path is if we are inspecting a
- composite font, first introduced in [1]. These composite fonts are extremely rare
+ Composite fonts were first introduced in [1]. These composite fonts are extremely rare
because:
1. None of the preinstalled fonts on either OS X nor iOS are composite fonts,
2. WebKit does not support loading web fonts from composite font files, and
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
