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

[Allan Sandfeld Jensen]

On Tuesday 13 June 2006 17:59, Mike Reed wrote:
> ...
> <input type="checkbox" name="box" checked="checked" />Test
> <input ...>
> ...
>
> When I draw this page, I see a box at the end of "Test". "Test" is
> comming into Font::drawText() as a 5 character string, with a CR (or
> LF, don't remember which) at the end. In my font, that draws as a box.
>
> Is it correct that the parser didn't strip that, or convert it into a
> space? If so, is my port expected to strip these sorts of characters
> each time I measure or draw (hurting performance)? 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.
>
> If I am required to handle these control characters, is there a list
> of exactly which the parser will pass through?
>
No, it will let a lot of weird unicode things through, but mostly NBSP, LF, CR 
and TAB are issues. The rest you can just ignore, since it would required 
changes elsewhere to support as well. You can instead make a list of what you 
want to support, or use a generic isSpace function. (don't be too afraid of 
speed, drawing is much slower than replacement anyway).

I had the same issue when implementing the white-space parsing in KDE's KHTML. 
The quick and dirty solution was to do a one time replacement (keeping an 
extra white-space cleaned string), but this ruins editing and cost a little 
memory.

The best solution would be to fix bidi.cpp so it doesn't include 
control-characters in the strings to draw. This would mean splitting strings 
that was separated with new-lines or tabs and place them one space apart.

The current method in WebCore pretty much depend on being in control of the 
font rendering layer. 

`Allan