[Waba-spec] A Font counter-counter proposal

[Sean L. <se...@cs...>]

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