As I pointed out in the past, use several different "charset" names
for the brain-dead unified character set, such as "ISO-10646-C",
"ISO-10646-J" or "ISO-10646-K", then.
It can't do everything of course as was pointed out in the original text,
but it helps in the most common situations.
Having different charset names do everything.
Except perhaps tell me that I can use a ISO-10646-J font if I don't have a
ISO-10646-K font and
That's no exception.
Implementation may use a ISO-10646-J font if it don't have a ISO-10646-K
font, regardless of whether the content-language is JA, KO, EN or EL.
Implementation may use a US-ASCII font if it don't have a ISO-10646-7
font, regardless of whether the content-language is JA, KO, EN or EL.
The behaviour is completely controlled by "charset" and has nothing
to do with "content-language".
it will look "almost right but maybe a bit annoying to
a native speaker".
Native speaker on what? Here, "charset" only is discussed. Without
content-language information, you can't say "native speaker".
Enough so that a Korean will be able to make more
sense out of it than "ISO-10646-K font does not exist. Cannot display
body part".
So will Greek, if he views text, which is originally represented in
Greek alphabet in ISO-10646-7, in ASCII,
Of course, people avoid to use such poor applications.
This situation can be solved by tables in the program or special cases
that recognise such character sets, but there is a problem with keeping
up with the latest list of near-equivalences.
It has nothing to do with "content-language".
I will concede defeat and won't hold up the progression of the draft to
standard status, but I don't have to like it.
Language tag is the thing we definitely need for the multilingual
Internet.
Masataka Ohta