> I may be wrong, but with CJK text don't you often have to know whether
> to render that text in a Korean, Japanese or Chinese form? If that text
> is say in the Japanese langusge you could probably use any number of
> Japanese fonts - so it isn't fonts we have to specify - I'm not talking
> "optimal rendering" here, only "intelligible rendering" for users who speak
> and read a particular language.
What I think Mark is saying (correct me if I'm wrong, Mark) is that the vast,
vast majority of documents will be monolingual, and that most of the
multilingual documents will be mixing languages that don't have conflicting
glyphs for the same characters. In these cases, it's almost always safe to
assume that the document is in the reader's language and that the user already
has his system set up to display that language correctly (which would generally
mean having a proper default font).
Where you'd get into trouble with this is when you _do_ have a multilingual
document with conflicting glyphs for the same character, such as Japanese and
Chinese or Arabic and Urdu. In these cases, if you're viewing them with a
plain-text editor, that editor is not going to be equipped to handle multiple
fonts in the document, period. This is true whether the tags for selecting
fonts (whether language tags or actual font tags) are embedded in the document
or generated on the fly somehow by the editor. The fact is, as soon as you have
the notion of using different fonts for different parts of the document, it's
not plain text anymore-- it's styled text.
The best a user would be able to do in that situation would be to switch the
font for the whole document back and forth for the different languages, or to
put up with the problem. In some cases, such as Arabic and Urdu, it shouldn't
be a big deal. The Nastaliq style of the Arabic alphabet is perfectly
acceptable and intelligble to readers of Arabic, for example.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:58 EDT