Thread: RE: [Waba-spec] Re: A Font counter-counter proposal
Status: Abandoned
Brought to you by:
bornet
From: Isao Y. <IYamashita@Vetronix.com> - 2001-11-28 03:03:07
|
> How does _Java_ handle this for Win32 then? > > It seems to me that rather than this being a Font issue, this is an > implementation issue better handled at the native level when a user > requests a drawText() (or as I'm proposing rewriting it, a drawString() > or drawChars() :-). Your native implementation of drawText() basically > gets handed a string of unicode characters, and a font to draw them in. > If the font is a "Japanese" font according to your operating system, > then you take the unicode characters requested and map them into the > appropriate hi-bit escape value ASCII gunk necessary to render them > correctly. If the font is a "Cyrillic" font, you do the same thing. > > It seems to me that the software developer shouldn't even know that this > is going on. If he wants an Hangul (Korean) character like ?, he writes > drawText("\u3333"). Similarly, if he wants a Han (CJK) character like ? > then he writes drawText("\u5555"). If the system is presently not > drawing with a Hangul font or Han font or whatever, then it either draws > a stub character (on the Mac, it's a square box), or it switches > temporarily to some Hangul or Han font that's appropriate, draws the > character however necessary, and then switches back. > > [BTW, I'd be very interested in knowing who was capable of viewing the > characters I wrote above in their email! MacOS X is a wonderful > system.] > Well all right, but the developer isn't writing in ASCII. He's writing in Unicode. So if you get a Unicode character your current font is capable of rendering, you render it. If you get a character you don't know how to render, you either give a filler character, or you figure out how to switch to a different font to render that character and then switch back. Both are fine. But I feel we should avoid any platform-specific features in the core spec. *** With my system at the office, they're just blank rectangles. I guess I have to install fonts in the system in order to display them. Anyhow, I see the difference in our view here. I'm not arguing or anything, but the way I was seeing the implementation is that, you can type in characters in both ways, either "\u5555" or "?(the rectangle)", so that a coder can just type in the characters as they are displyed on his/her editor. In my case, I just typed in Kanjis with no problem, but I had to specify the values for Cyrillic characters. If we can just force them to type in the values, then it makes my life much easier. If this will be the case, we have to use one of those Unicode capable text editors. Surprisingly, it seems Java compiler takes both formats and encodes in UCS format (With JDK 1.2.2. Maybe detecting from the default OS code-page, I guess). So, I thought I ought to handle both ways too somehow. Any more thoughts? Isao |