I'm waiting for the review of the actual gdk code :(
On 6/14/06, Mike Reed <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> 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 > ([EMAIL PROTECTED]) > > _______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
