[webkit-dev] drawing LF/CR/etc.
mikerreed at gmail.com
Wed Jun 14 09:59:03 PDT 2006
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.)
> (hyatt at apple.com)
More information about the webkit-dev