[webkit-dev] Safari and complex script rendering

[David Hyatt]

WebCore has two font rendering code paths: the simple path and the  
complex path.  WidthIterator is only used by the simple path.  For  
complex scripts, different code paths are used that involve the OS  
text engines more (ATSUI/CoreText on Mac, Uniscribe on Windows).

Check out platform/graphics/Font.cpp.

Functions usually branch based off a canUseGlyphCache method that  
inspects the text run to see if it contains complex script:

For example, here is the drawText function:

void Font::drawText(GraphicsContext* context, const TextRun& run,  
const FloatPoint& point, int from, int to) const
{
    ...
     if (canUseGlyphCache(run))
         drawSimpleText(context, run, point, from, to);
     else
         drawComplexText(context, run, point, from, to);
}

dave

On Sep 28, 2008, at 3:15 AM, Paul Pedriana wrote:

>>> ... this is not a WebCore issue, so there is nothing you can do
> in WebCore to fix it.
>
> When I look at WebCore's WidthIterator::advance function, it doesn't
> seem to me to be savvy to complex script. It looks to me like it walks
> through a Unicode string and replaces character clusters with  
> individual
> glyphs. This approach works for most scripts but not complex scripts
> such as Arabic and Devanagari. The problem, as you may well be  
> aware, is
> that there are many OpenType-directed substitutions, ligations, and
> "un-ligations." This is unrelated to Arabic's RTL nature unrelated to
> simply contextual alternates resulting from cursiveness. It seems to  
> me
> that complex script would have to be supported by something other than
> WidthIterator::advance (is it?).
>
> If WebCore (or WebKit in general) supports complex script correctly  
> then
> I wonder what I am missing regarding the above statements.
>
> Paul
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev