From: Kenneth Whistler (kenw@sybase.com)
Date: Thu Sep 26 2002 - 19:17:49 EDT
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 : Thu Sep 26 2002 - 20:08:59 EDT