From: Mark Davis (mark@macchiato.com)
Date: Fri Sep 27 2002 - 00:07:17 EDT
> not to replace one broken model (code page = language) with
> another broken model (language = font preference).
I would add to that that I suspect that given the number of documents
that fail to tag with language, or even worse yet, tag with the wrong
language, that other approaches may give generally better results. The
main area of concern is CJK, and I suspect that in a great many cases
the user is probably better off either:
- simply using a font set according to the user's own preference, or
- having a bit of smarts in the program for heuristically picking
among C, J and K.
Mark
__________
http://www.macchiato.com
◄ “Eppur si muove” ►
----- Original Message -----
From: "Kenneth Whistler" <kenw@sybase.com>
To: <tex@i18nguy.com>
Cc: <unicode@unicode.org>; <kenw@sybase.com>
Sent: Thursday, September 26, 2002 16:17
Subject: Re: glyph selection for Unicode in browsers
> 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
>
This archive was generated by hypermail 2.1.5 : Fri Sep 27 2002 - 00:53:06 EDT