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) || … ? 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. I look forward to seeing a patch! _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
