Thread: [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 |
From: Guilherme C. H. <gu...@us...> - 2001-11-27 10:58:19
|
Maybe you could adopt what i made in SuperWaba. My String class has this: /** The bytes are converted to char and vice-versa using the CharacterConverter associated in this charConverter member. */ public static waba.sys.CharacterConverter charConverter = new waba.sys.CharacterConverter(); /** Creates a string from the given byte array. The bytes are converted to char using the CharacterConverter associated in the charConverter member. */ public String(byte []value, int offset, int count) { chars = charConverter.bytes2chars(value,offset,count); } /** return this String as bytes.The chars are converted to byte using the CharacterConverter associated in the charConverter member. @since SuperWaba2.0beta4 */ public byte []getBytes() { return charConverter.chars2bytes(chars,0,chars.length); } And this is the CharacterConverter class: /** This class is used to correctly handle international character convertions. * The default character scheme converter is the 8859-1. If you want to use a different one, * you must extend this class, implementing the bytes2chars and chars2bytes methods, and then * assign the public member of java.lang.String charConverter to use your class instead of this default one. * Note that the java.lang.String mentioned above is located at org/superwaba/palm/classes/java.lang.String. */ public class CharacterConverter { public static char[] bytes2chars(byte bytes[], int offset, int length) { char []value = new char[length]; int i = 0; while (length-- > 0) { byte b = bytes[offset++]; value[i++] = (char)(b >= 0 ? b : (256 + b)); } return value; } public static byte[] chars2bytes(char chars[], int offset, int length) { byte []bytes = new byte[length]; int end = offset+length-1; int i = 0; byte b; for (; offset <= end; offset++) { char c = chars[offset]; if (c <= '\377') b = (byte)c; else { if ('\uD800' <= c && c <= '\uDBFF') { if (offset == end) // we must skip one byte, but no more bytes avail? break; offset++; } b = (byte)'?'; } bytes[i++] = b; } if (i != length) { byte []temp = new byte[i]; Vm.copyArray(bytes,0,temp,0,i); bytes = temp; } return bytes; } } So, if someone need a special conversion, just implement it and set the public static member of String class. regards guich |
From: Guilherme C. H. <gu...@us...> - 2001-11-27 14:10:17
|
Hi, I'll post a list of my changes on the VM so that you can know what i done. The problem is that the list is huge (more than 70 changes) and i cannot precise very well what had changed. Also, currently i'm out of time to do that. So, please give me one more week. If you take a look at my current release and compare the executeMethod part, you may see many of them. The Waba 1.0 timmings are 143010/33340/8860/25940/126460/53250 (graphics+native method/ loop/ field/ method/ array/ string) The current release has: 76100/24180/4980/14870/94330/29360. I expect that when i finish implement the huge memory model, all timings will fall down about 10%. All tests runs the same program (examples/bench) and in my Palm Professional handheld. regards guich |