Hi guys! On Thu, 2002-03-21 at 19:42, Anthony Fok wrote: > On Wed, Mar 20, 2002 at 02:43:49PM +0800, James Su wrote: > > I have done the HKSCS-2001 patchs for glibc, XFree86 and qt-2.3.x. But I > > have no enough time to test them. And the most important, I have no ttf > > font that comforms to HKSCS-2001 :-( > > That's true. I guess that even those 70000+-glyph super CJK fonts by > Founders may not totally conform to HKSCS-2001 yet because they may not > have compatibility mappings (in PUA) and the 30 or so characters not > yet accepted into ISO 10646.
Perhaps we can use tools such as oto[1] to modify the font's cmap table. (One question: is the cmap table in UCS-2, UTF-16, or UCS-4/UTF-32?) [1] http://sourceforge.net/projects/oto But Founder's font is not free, is it? [...] > The ITSD provides a font on their website. It only uses the EUDC, but > could be a start. BTW, Roger says that the *.TTE may be used under > XFree86. I just haven't tried it yet. :-) Well, a *.TTE is just a normal TrueType font. What Windows does is that it will search for a glyph in a normal font first, and if it can't find the glyph for a particular codepoint, it'll look in the associated .TTE. Rather like X's fontset concept. Having said all that, please note that the current Big5-HKSCS X locale has problems if you want to use a separate HKSCS font (as a .TTE) in addition to a normal Big5 font. I guess that with the X locale database's limitations -- it insists on ISO-2022 terminologies like GL/GR -- to fully support this mode of operation we need an XOM (X Output Method) module. No, I'm not volunteering to write one. :) And I've heard that in XFree86 4.2 (X11R6.6), everything's different again. But I won't have time to check out 4.2 soon, until it is uploaded to Debian sid anyway. :) [...] > I am not too happy that the U+20021..U+2F9D4 to Big5-HKSCS mapping > takes up so much space (nearly 70 KB for just 1651 entries) because of > the sparse array. Anyhow, BIG5HKSCS.so grew from 115165 bytes to > 185240 bytes here. Not a big deal, but even the big GB18030.so is only > 130356 bytes... :-) I am thinking of using a hash instead for that > area, but that'll be an experiment for another day. Fun stuff! :-) Heh. Still better than the giant "switch ... case ... case ..." block that I first thought of. :) Or perhaps you can have a sorted mapping table with which you can do a binary search on. Cheers Roger -- Roger So Debian Developer Sun Wah Linux Limited i18n/L10n Project Leader Tel: +852 2250 0230 [EMAIL PROTECTED] Fax: +852 2259 9112 http://www.sw-linux.com/ _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
