W3C home > Mailing lists > Public > www-international@w3.org > July to September 2002

Re: glyph selection for Unicode in browsers

From: Vinod Balakrishnan <vinod@adobe.com>
Date: Fri, 27 Sep 2002 12:38:45 -0700
To: Tex Texin <tex@i18nguy.com>, Jungshik Shin <jshin@mailaps.org>
CC: WWW International <www-international@w3.org>
Message-ID: <B9BA01D5.164D%vinod@adobe.com>

From my own experience dealing with similar problems, this is what I have to
say

1. We need a font like "Tahoma" on XP/WIN2k ( font with Unicode cmap
and limited glyph sets)  on all the platforms, where application can set
font to Tahoma and pass in any Unicode strings. Once font is set to Tahoma,
operating system will go ahead and pick the right font for the missing
glyphs. So this font name can be mentioned in the HTML pages.

2. There is a way to specify "Typographic preference" to handle CJK in the
API level while rendering the text using the font in step 1. ( Right now it
goes to default operating system script in certain systems)

3. Browser should take the accept language or other application preference
to set the appropriate "typographic preference" for choosing the right fall
back font by the OS.

Unfortunately we are still missing some nuts and bolts .


-Vinod




> 
> Jungshik,
> 
> I used characters that should display differently. Some punctuation and
> some like (I think it is) the bone character.
> 
> However, feel free to suggest a list of characters that should be
> distinctive and I'll post a page with them that we can all review
> whether there are differences or not on various platforms, browsers,
> etc.
> 
> I agree for many characters there should be no differences.
> 
> tex
> 
> Jungshik Shin wrote:
> 
>>   Actually, you might have had hard time telling the display difference
>> depending on what characters you used for your testing EVEN IF you
>> configured browsers to use different (but with __very similar__ design
>> principles and look/feels) Unicode-cmapped (but NON-pan-script) fonts
>> for TC,SC, J and K *under MS Windows*.  This difficulty demonstrates
>> that CJK Unification in Unicode/10646 is not such a big problem as some
>> people tried to make it.
>> 
>>   Jungshik
Received on Friday, 27 September 2002 15:38:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:16:59 GMT