[Waba-spec] A Font counter-counter proposal
Status: Abandoned
Brought to you by:
bornet
From: Sean L. <se...@cs...> - 2001-11-27 03:06:34
|
Isao wrote: > I'd like to add couple of things on top of "Font", "Image", and > "Graphics" > classes. > > Font class: > Since some of OS don't support Unicode natively, > I'd like to add a code-page attribute to this class as an alternative. > For this, I need "String locale;" > "public Font(String name, String locale, int style, int size);", > "public String getLocale();" > "public void setLocale(String locale);" > to be added to this class. > > What I have right now is that an user passes "jp", "ru", etc. to > "locale", > and VM chooses the closest match of code page to the specified locale. I'm trying to understand what you're proposing here. A Font, as far as Java is concerned, is a family + size + formatting. Some fonts support certain character glyphs, some don't. By code-page, I assume that you're saying that something is displaying (say) the Cyrillic range of the Unicode glyph-space. But why not just switch the font automagically when it has to display a given character Foo outside its range? Is this a Palm problem I'm missing somewhere? On the other hand, if you have fonts which only work in certain areas, why not specify this in the name string? As in: new Font("Cyrillic", Font.BOLD + Font.ITALIC, 18); Clue me in, I'm probably not seeing it. Now, there *is* an issue if you want to display Chinese (say) and don't know which font is capable of doing this. You'd like an equivalent of Font.forUse(...). One approach is: Change my proposed public static native String[] getNames(); to public static native String[] getNames(String script); Or instead of deleting it, you could redefine getNames() to be { return getNames(nil); } That way you can look up all the available fonts for a given script; of course you'd need to be able to provide such a thing programmatically (on the Newton we'd have to just hack it and create a little list of various-language fonts we know about). Programmers should be informed that if the returned array is empty, they should tell the user they can't figure out what font to use for a given script, and perhaps ask the user to pick from a list. Instead of defining script in terms of "locale" (which I think is not a good idea for fonts), instead define it in terms of script name. Unicode has some standard script names, see http://www.unicode.org/unicode/reports/tr24/charts/ . Stuff like Latin, Armenian, Han, Hiragana, etc. If you like you can be more sophisticated and allow the names to be separated by spaces, and it returns any fonts which provide all three scripts, as in "Han Hiragana Hangul". If nil is passed in, or the string is empty, then ALL fonts are returned. Further, the Font.forUse()... etc. methods should assume that the user's pre-defined script for his system (Japanese, Latin, etc.) biases the font choice for the given use. Though I'd strongly suggest that any such fonts should *also* be able to display Latin. The nice feature of this is that there are Unicode scripts which aren't locale-based: like "Sm", which is math symbols, or "No", which is special kinds of number symbols. As to your examples, "jp" would be covered probably by any font which can do "Han Hiragana" or "Han Katakana". "ru" would be covered by any font which can do "Cyrillic". Sean |