[webkit-dev] drawing LF/CR/etc.
Allan Sandfeld Jensen
kde at carewolf.com
Tue Jun 13 09:44:41 PDT 2006
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
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.
More information about the webkit-dev