[webkit-dev] drawing LF/CR/etc.

[Mike Reed]

Got it. I just peeked at TOT, and I see the new (for me at least)
GlyphBuffer and GlyphMap files. Can't wait to sync to the tip...

On 6/13/06, David Hyatt <hyatt at apple.com> wrote:
> On Jun 13, 2006, at 8:59 AM, Mike Reed wrote:
>
> > Is it correct that the parser didn't strip that, or convert it into a
> > space?
>
> Correct.  The original string must be preserved, since this is
> relevant both for HTML editing (to not mangle the source) and for CSS
> white-space, which can be dynamically set at any time to values like
> "pre" (thus indicating that the whitespace should be preserved).
>
> > If so, is my port expected to strip these sorts of characters
> > each time I measure or draw (hurting performance)?
>
> No.  Your port should be hooking in at a lower level than drawText.
> Font.cpp is completely cross-platform, and you should be using all of
> it if you can.
>
> Check out the files in the win and mac directories under platform to
> see what methods you have to implement (all the Font*** and Glyph***
> classes).  Much of the font layer is cross-platform, and there's
> really only a handful of methods you have to implement.  For simple
> text, we handle tabs, newlines, etc. for you.  You only have to deal
> with it for advanced scripts (the ***ComplexText methods).
>
> > If I had complete
> > control over all my fonts, I could wack their cmap tables to ensure
> > that all control characters mapped to zero-width spaces, but I don't
> > have the luxury.
> >
>
> That's basically what we do down the fast code path (which is cross-
> platform).  We have a cached glyph map that is hacked to map newlines
> and tabs to spaces.  (The map is only used for those characters when
> the white-space mode indicates they should not be preserved.
> Otherwise the white-space handling kicks in at a higher level and
> avoids the glyph map when processing those characters.)
>
> dave
> (hyatt at apple.com)
>
>