Follow up patch after r188566
authormmaxfield@apple.com <mmaxfield@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 18 Aug 2015 02:44:14 +0000 (02:44 +0000)
committermmaxfield@apple.com <mmaxfield@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 18 Aug 2015 02:44:14 +0000 (02:44 +0000)
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@188569 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WebCore/ChangeLog

index cd90f58..81a7edd 100644 (file)
 
         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