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

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

> 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