On Tue, 9 Aug 1994, Masataka Ohta wrote:
7. Character set considerations
Codes are always expressed using US-ASCII (a-z).
The issue of deciding upon the rendering of a character set based
on the language encoding is not addressed in this memo; however,
the author cautions against thinking that such a decision can be
made correctly for all cases unless means of switching language in
the middle of a text are defined (for example, a rendering engine
that decides font based on Japanese or Chinese language will fail
to work when a mixed Japanese-Chinese text is encountered)
[...]
The section should be:
7. Character set considerations
Codes are always expressed using US-ASCII (a-z).
The issue of deciding upon the rendering of a character set is
controled only by charset paramter in Content-type header and
has nothing to do with the language tag.
I know you hate CJK unification Masataka, but as I've pointed out in the
past, the language tag _can_ have something to do in deciding upon the
rendering of a character set to help disambiguate the unification for those
people who do choose to use a unified character set despite your objections.
It can't do everything of course as was pointed out in the original text,
but it helps in the most common situations.
Implementations should be free to choose whether to take the language tag
into consideration or not when choosing an appropriate font. Your
requirement is too strict Masataka. If you don't want to look at
Content-Language in your implementations, that's your decision. But
let the rest of us design our software the way we see fit.
Let the Internet evolve to choose what it believes to be the correct way
to do things. Maybe you'll be right and I'll be wrong, but we won't know
that until we let the users decide. I certainly recognise your greater
experience in Asian language charsets, but that's no excuse to restrict
the flexibility of a perfectly valid tool before the market decides whether
the flexibility is needed or not.
Cheers,
Rhys.