RE: [Waba-spec] A Font counter-counter proposal

[Isao Y. <IYamashita@Vetronix.com>]

> 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?
> 
	>>>
	First, let me say I like the word "automagically".
	I think this would be a good idea.
	By detecting Unicode range, I can automagically change character
sets.
	The reason for my initial proposal was that I had to match the fonts
with 
	proper character sets. This is a requirement for code-page based
	Win32 environment (WinCE, NT, 2000, XP are Unicode based).

> 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.
> 
	>>>
	Well, there are multiple fonts available for a given character set.
	Like there are two default Japanese fonts, "mincho" and "gothic".
	So this option is not really usable.

> 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.
> 
	>>>
	Mmm, sounds like we 'd have to embed many look-up tables somewhere.
	I'm not sure about this and it doesn't make me feel comfortable,
	as it makes blow up Waba's code size for not-so important feature.
	I'd still like to keep this issue to a coder's discretion.

> 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.
> 
	>>>
	Only up to ASCII code 127. For instance, in Japanese OS,
	ASCII code up above 128 are used as flags for double byte encoding.
	So, I can't mix Japanese characters with alphabets with accent marks
	(as it is the case for code-page based OS).

> 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.
> 
	>>>
	Ah, sounds good.








> _______________________________________________
> Waba-spec mailing list
> Wab...@li...
> https://lists.sourceforge.net/lists/listinfo/waba-spec