Most fonts are going to cover one or two traditional charsets.
I'm not going to have any Arabic in my Baskerville. I might have
a Unicode font lying about, but I would expect to use it as a
backstop to better fonts in the languages I'm really interested in.
As it is, I don't have a Unicode font lying about.
| In any other alternative I would know, making HTML truely
| multilingual would mean that implementation is without
| any clear end.
| b) Not knowing whether I will be able to fully render the document
| is not worse than what we have at present, e.g. with L10N.
|
| This may be somewhat beyond the current discussion points, but
| I would for the moment propose that there is no need to think
| about a system that, in a more or less complex way, identifies
| code ranges, and so on.
| My main argument is that there is little difference whether I
| get a document in e.g. Bengali, and can't display it, or whether
| I can display that document, but can't read it. And I can assume
All the difference in the world. If I can display it I can print
it; I can ask a literate Bengali speaker to read it for me; I
can start learning the language. We don't need to get into the
literary capabilities of the human users of clients. The question
here is purely how we infer or describe system capabilities once
we widen drastically the doc charset.
-- Terry Allen (terry@ora.com) O'Reilly & Associates, Inc. Editor, Digital Media Group 101 Morris St. Sebastopol, Calif., 95472 occasional column at: http://gnn.com/meta/imedia/webworks/allen/A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html