Hi,
While trying to make Mozilla-Xft support non-BMP characters with fonts like CODE2001.TTF (with pid=3/eid=10 Cmap), I found that freetype and Xft need a little change. Details are sent to linux-utf8 list (http://mail.nl.linux.org/linux-utf8/2002-12/msg00000.html) and Bugzilla (http://bugzilla.mozilla.org/show_bug.cgi?id=182877). Below is a part of my message to linux-utf8 list related to Xft. ------------- I also have to extend XftTextExtents16() included in fcpackage-2.1 to deal with UTF-16 (instead of UCS-2). Xft2 has XftDrawStringUtf16() in addition to XftDrawString16() (the latter is for UCS-2). I thought about adding XftTextExtentsUtf16(), but it appears that it's more convenient for programs like Mozilla which uses UTF-16 for internal string representation when XftTextExtents16() is extended to support UTF-16. Again, there's a little speed penalty. Below are links to FT2 patch (against 2.1.3) and Xft patch (against fcpackage 2.1) http://bugzilla.mozilla.org/attachment.cgi?id=107852 : FT2 patch http://bugzilla.mozilla.org/attachment.cgi?id=107858 : Xft patch There are a couple of screenshots along with Mozilla patch and a couple of sample pages with non-BMP characters at http://bugzilla.mozilla.org/show_bug.cgi?id=182877 ----------- Extending XftTextExtents16() to support UTF-16 is similar to the extension of Win32 'W' APIs to support UTF-16. Some people may not like it. However, it seems not so bad an idea and I even think that XftDrawString16 may as well be extended in a similar manner. I'm not a big fan of UTF-16, but neither am I very much against it. IMHO, it'd be very nice if either extending XftTextExtents16() or adding a new function XftTextExtentsUtf16 (a la XftDrawStringUtf16() ) is done before the release of XFree86 4.3. Keith, what would you say? Jungshik _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
