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. > 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(). 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 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
