- From: Tex Texin <tex@i18nguy.com>
- Date: Thu, 26 Sep 2002 21:55:18 -0400
- To: Kenneth Whistler <kenw@sybase.com>
- CC: unicode@unicode.org, WWW International <www-international@w3.org>
Ken, thanks. I absolutely agree. Yes code page was not a good indicator of language, but it was used that way by some applications. And yes, Language should not dominate font selection, it should influence it. Other typographic preferences also must be accomodated. Well said. In the case of HTML, XML, CSS, ways to specify typographic preferences exist, and language can be expressed via "lang". We just need browsers and other user agents to make use of the lang information as part of font selection. tex Kenneth Whistler wrote: > > Tex, > > > 3) The language information used to be derived > > dubiously > > > from code page and is > > missing with Unicode, and architecture needs to accomodate a better > > model for bringing language to font selection. > > The archetypal situation is for CJK, and in particular J, > where language choice correlates closely with typographical > preferences, and where character encoding could, in turn, > be correlated reliably with language choice. > > But in general, the connection does not hold, as for data > in any of hundreds of different languages written in Code Page 1252, > for example. > > What you are really looking for, I believe, is a way to > specify typographical preference, which then can be used to > drive auto-selection of fonts. > > I don't think we should head down the garden path of trying > to tie typographical preference too closely to language identity, > however we unknot that particular problem. This could get > you into contrarian problems, where browsers (or other tools) > start paying *too* much attention to language tags, and > automatically (and mysteriously) override user preferences > about the typographical preferences they expect for characters. > > What is needed, I believe, is: > > a. a way to establish typographic preferences > b. a way to link typographical preference choices to > fonts that would express them correctly > c. a way to (optionally) associate a language with > a typographical preference > > And this all should be done, of course, in such a way that > default behavior is reasonable and undue burdens of understanding, > font acquisition, installation, and such > are not placed on end-users who simply want to read and print > documents from the web. > > A tall order, I am sure. But as long as we are blue-skying about > architecture for better solutions, I think it is important > not to replace one broken model (code page = language) with > another broken model (language = font preference). > > --Ken -- ------------------------------------------------------------- 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, 26 September 2002 21:55:50 UTC