On Dec 2, 2009, at 10:52 AM, Kevin Ollivier wrote: > Hi Dan, > > On Dec 1, 2009, at 8:29 AM, Dan Bernstein wrote: > >> >> On Nov 29, 2009, at 10:27 AM, Kevin Ollivier wrote: >> >>> Hi all, >>> >>> The wx port is starting to look at getting proper support for complex text, >>> and one of the first places I started looking at was the Win and Mac port >>> implementations. I noticed that the complex text code in FontWin.cpp and >>> FontComplexTextMac.cpp is largely the same, passing the heavy lifting down >>> to their respective complex text controllers, and I actually wondered if >>> they could be merged if there were some tweaks to the APIs to make them >>> compatible. >>> >>> That led me to wonder if we couldn't make ComplexTextController one of our >>> platform classes and have USE() defines to determine the implementation. >>> Then we could move the drawComplexText, floatWidthForComplexText, and >>> offsetForPositionForComplexText into Font.cpp guarded by that USE() define. >>> The wx port can provide the native font handles the Win/Mac controllers >>> need, so it'd really be great if we could just add these into our build to >>> get complex text support working without having to implement the complex >>> text methods differently for each platform. >>> >>> BTW, I actually already did get UniscribeController compiling, actually, >>> but on Windows I had to have the build script copy it to >>> platform/graphics/wx because MSVC implicitly puts the current directory >>> first on the path, which was causing it to pick up >>> platform/graphics/win/FontPlatformData.h instead of the wx one when >>> compiling that file. :( So that's something else that would need to be >>> addressed if ports can start sharing these files. >>> >>> Thanks, >>> >>> Kevin >> >> Hi Kevin, >> >> This sounds like a generally good idea. ComplextTextController is already >> using USE() macros to select between Core Text and ATSUI. I am not entirely >> sure how the the *ComplexText() methods will be guarded in Font.cpp in your >> proposal. Are you suggesting something like >> #if USE(ATSUI) || USE(CORE_TEXT) || USE(UNISCRIBE) || … >> ? > > I was thinking we'd create some WTF_USE_COMPLEX_TEXT_CONTROLLER so that it > would be easier to opt out of using it, since a port may define / use > WTF_USE_ATSUI or WTF_USE_CORE_TEXT for purposes other than supporting complex > text.
The USE() macros are intended for specifying platform technologies, not parts of the engine. I think it would be more appropriate to use ENABLE(COMPLEX_TEXT) to control the feature. > >> There are still some differences in behavior between ComplexTextController >> and UniscribeController, so you’d need to find a way to accommodate them or >> eliminate them. > > In terms of public API, I think merging the changes shouldn't be too > difficult. IIUC finalRoundingWidth() can probably just remain 0 on Win, and > the "ignore writing direction" optimization on Mac can be put in the common > API but just be ignored under Windows. > > The only thing I'm not sure about is that Mac and Win get the run's width in > different ways, but I'm not quite sure why they do it differently00. Either > approach would seem to work for both platforms. Mac calculates the total > width when the ComplexTextController is created, while on Win to calculate it > you have to call advance(run.length()) then get the value using > runWidthSoFar(). Since the glyph used for the ith character—and the width of the glyph used for the ith character—may depend on the i+1th character, you have to generate glyphs and advances for the entire run before you can determine any widths, so ComplexTextController does it in its constructor. What UniscribeController leads to incorrect selection rects in some cases. > The quick fix would seem to be to just have both platforms call > advance(run.length()) and then use runWidthSoFar(), but I suspect that would > hurt performance on Mac. Another way that might fix it would be to call > advance(run.length()) in UniscribeController::UniscribeController then set > m_totalWidth = m_runWidthSoFar and reset m_currentCharacter and > m_runWidthSoFar to 0. Lastly, we could take the guts of advance and put it > into something like a Win version of adjustGlyphsAndAdvances() that sets > total width. Do you have any suggestions / preferences for how to tackle this? I would like UniscribeController to become more like ComplexTextController, not the other way around, but I wouldn’t like to make either one slower than. If the UniscribeController constructor advanced to the end, but then reset its current state, it would end up doing some amount of work twice in some cases, because the adjusted glyphs and advances it had produced in the first pass would be lost. Generally speaking, the way to fix this is to add “adjusted advances” and “adjusted glyphs” vectors to UniscribeController, like the ones ComplexTextController has. You’d probably also need a vector of runs (corresponding to Uniscribe “items”), but the differences between Uniscribe and the Mac complex text engines may complicate this. > >> I look forward to seeing a patch! > > Cool, I don't think this will take too long to work up. :) > > Thanks, > > Kevin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
