Around 12 o'clock on Jul 8, Edward Lee wrote:
> > The question is whether we should mark certified GB18030 fonts as suitable > > for zh-TW as well as zh-CN. I have the GB18030 varient of SimSun here in > > TrueType and it does not have the traditional Chinese codePageRange bit > > set, but does cover the codepoints found in Big5. > > There are `two' Traditional Chinese fonts here. In zh-tw the > radical/stroke of some glyphs are differrent with the TC glyphs > in GB18030 fonts. Then the goal should be to identify GB18030 fonts as only zh-cn. For users who have only a GB18030 font and no traditional Chinese fonts, the zh-cn mark will cause that font to be preferred over a Japanese or Korean font, but for people with fonts marked zh-tw, they'll always get the zh-tw font instead of a zh-cn font. For GB18030 fonts that come in TrueType format, the codePageRange bits already set the appropriate hints -- they indicate the font is suitable for simplified Chinese, but do not indicate that the font is suitable for traditional Chinese. Clearly, I should use the codePageRange bits to help select Han language targets -- when any of the Han codePageRange bits are set, exclude languages which aren't listed in the codePageRange bits. > Not only typographic style, but different radical/stroke. That's really bad; I know that looking up Chinese characters in my Japanese dictionary is often an adventure. > Is there any other solutions? Yes, we have lots of possible solutions, I'm just searching around for the right one that will generate the best possible result for the greatest number of people. What might be idea is to be able to do is order the available Han languages and let people configure the 'fallback' order. A user might prefer a Japanese font for Chinese text when they have no Chinese fonts. Right now, all I've got is three levels: matching language and country, matching language and matching neither -- the user in this case will essentially get a random font with Han support when they don't have one suitable for the target language; the font selection will be driven strictly by Unicode codepoints. Obviously, I'd like to avoid introducing arbitrary configuration complexity if this solution isn't adequate; we've already got a pretty sophisticated system that will take some considerable understanding before people can really get the results they want that it is capable of producing. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
