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

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

Isao Quoth:

> 	The reason for my initial proposal was that I had to match the=20=

> fonts with
> 	proper character sets. This is a requirement for code-page based
> 	Win32 environment (WinCE, NT, 2000, XP are Unicode based).

How does _Java_ handle this for Win32 then?

It seems to me that rather than this being a Font issue, this is an=20
implementation issue better handled at the native level when a user=20
requests a drawText() (or as I'm proposing rewriting it, a drawString()=20=

or drawChars() :-).  Your native implementation of drawText() basically=20=

gets handed a string of unicode characters, and a font to draw them in. =20=

If the font is a "Japanese" font according to your operating system,=20
then you take the unicode characters requested and map them into the=20
appropriate hi-bit escape value ASCII gunk necessary to render them=20
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=20=

is going on.  If he wants an Hangul (Korean) character like =E3=8C=B3, =
he writes=20
drawText("\u3333").  Similarly, if he wants a Han (CJK) character like =
=E5=95=95=20
then he writes drawText("\u5555").  If the system is presently not=20
drawing with a Hangul font or Han font or whatever, then it either draws=20=

a stub character (on the Mac, it's a square box), or it switches=20
temporarily to some Hangul or Han font that's appropriate, draws the=20
character however necessary, and then switches back.

[BTW, I'd be very interested in knowing who was capable of viewing the=20=

characters  I wrote above in their email!  MacOS X is a wonderful=20
system.]

>> 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=20
>> Latin,
>> Armenian, Han, Hiragana, etc.  If you like you can be more=20
>> 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=20=

>> 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.

Well, if you can't query the OS to get this information, you might have=20=

to do it with tables or not at all.  The way I was envisioning it, if=20
the system can provide this stuff, it does.  If it doesn't, the array=20
that comes back is empty.  It would be an optional nicety, but it's not=20=

a deal-breaker for me, just an idea.


>> Further, the Font.forUse()... etc. methods should assume that the=20
>> 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).

Well all right, but the developer isn't writing in ASCII.  He's writing=20=

in Unicode.  So if you get a Unicode character your current font is=20
capable of rendering, you render it.  If you get a character you don't=20=

know how to render, you either give a filler character, or you figure=20
out how to switch to a different font to render that character and then=20=

switch back.  Both are fine.  But I feel we should avoid any=20
platform-specific features in the core spec.

Sean