Re: 1st Working Draft of Authoring Techniques for XHTML & HTML Internationalization Published

Hi,

I have trouble with the term "localized font name" because for many of the
asian fonts I know, they had native names for years and the ascii name, coming
later, is the localized version, localized for the US... ;-)

But you have a good point and font naming is a very big problem area. I know
Richard was trying to develop a list of fonts to use for the languages around
the world earlier in the year.

Your comment on font names could make a good FAQ. Jungshik, would you like to
create one?

I am not sure though that the behavior is the same for all operating systems
and/or browsers.
I am familiar with Microsoft and it is right from the underlying architecture
perspective. We would need to confirm the behavior for several user agents on
several systems with several languages, as you indicate by examples.

tex

Jungshik Shin wrote:
> 
> On Thu, 9 Oct 2003, Richard Ishida wrote:
> 
> > Congratulations to ourselves !   This announcement has just gone out on
> > the W3C home page.
> 
>   Thank you for your great work ! I just skimmed over it quickly
> and came up with a couple of comments.
> 
>   In 4.1 Choosing & specifying fonts, it has to be noted that
> whenever localized font names (family names) are specified (in CSS),
> all-ASCII font names should be specified alongside because localized
> font names (in characters outside US-ASCII) are not available on all
> platforms and nor  recognized by all user agents. For instance, the name
> of a font returned by Win32 font-related APIs depends on the default
> system locale so that on fonts whose name are   specified in Japanese
> (Chinese/Korean) [1] wouldn't be matched by most [2] user-agents running
> on non-Japanese(Chinese/Korean) Windows. Another example is fontconfig
> library used by both Mozilla and Konqueror on Linux and other free
> Unix. It doesn't yet support international localized font names. Yet
> another example is XLFD (X11 Logical Font Description) still widely used
> on commercial Unix despite a number of shortcomings. AFAIK, XLFD doesn't
> support anything other than US-ASCII in all its fields (including foundry
> and family name fields). Given all these, it's essential that family
> names be specified in US-ASCII only strings (along with localized names).
> 
>  In 14.1 Date & Time, it's adised that 'words for the month be used and
> an example (02 mar 2004) is given. I'm not sure of the wisdom of this.
> For speakers of European languages, that may be a good advice, but
> for East Asian users, that doesn't seem to as good (and I'm not sure
> of other regions/languages). At the minimum, YYYY-MM-DD format (as
> specified in ISO 8601) should be mentioned as a rather universal and
> culture/language-neutral alternative.
> 
>   Jungshik
> 
> [1] Win32 APIs return localized family names only on CJK windows.
> [2] It's certainly possible that user agents themselves can look 'deep'
> inside a font to figure out ASCII or localized family name even though
> the OS API doesn't.

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

Received on Thursday, 9 October 2003 20:48:43 UTC