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

David Hyatt hyatt at apple.com
Tue Jun 13 14:04:23 PDT 2006

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 mailing list