> Marco Cimarosti wrote:
> Yes: if you only speak one language, your computer only needs
> support for
> that language. And if you speak two, three, four... languages, your
> computers only needs support for those languages: why having
> a fifth one?
I'm not too concerned about support for Unicode in OS's, although that is an
important issue too. My concern is that of being able to read text on the
*web*. If I'm on a trip and want to read Swedish news on the net, then I
expect to be able to do so without having to locate a Swedish computer
first. I don't have much a problem reading Swedish on most non-Swedish
machines (e.g. I may need to twiddle with some settings), but it's annoying
that it does not work as-is. This situation is much worse for other
Take Polynesian languages for example, e.g. Hawaiian. This is a language
which is based on Latin with vowels with the macron accent mark and a
glottal apostrophe (the apostrophe is a real charcter, i.e. does not break a
word). It's very difficult for them to use their native language in web
pages, because there is no such thing as a Hawaiian version of Mac OS, or
IE, etc. Hawaiian web users rely on Unicode, but Unicode browsers and
Unicode platforms don't necessarily support Polynesian.
> In the case you speak a single language, Unicode is only
> needed if that
> language is written in an "Unicode-only" script (such as Ethiopic,
> Mongolian, Khmer, et al. which don't have legacy encodings).
A lot of people that rely on Unicode-only scripts do use (often
incompatible) propriatory encoding schemes. They are often forced to use
machines installed with anothe language (e.g. English) when using these
schemes. Web browsers should be able to accomodate these people without
having to rely on the OS for Unicode support.
> About web fonts, I don't think they are a bad idea, per se.
> However, they should be better used as a fallback for cases
> when the client
> computer does not have a suitable font. Why should I download
> a resource I
> already have?
Good point. CSS includes provisions for browsers to determine if they do
need to download font resources or not (the @font-face rule may contain a
unicode-range that specifies the used chracters, as well as the name of the
font, etc). It provides provisions as well for selecting suitable
replacements (through something called panose that describes visual aspects
of the font).
The problem today is that browsers typically do not support web fonts, let
alone in a smart way. It's the implementations and not the technology that
is to blame.
> Moreover, web fonts should be functionally equivalent to
> local fonts. E.g.,
> they should have all the functionality required by "complex
> script", and not
> force authors to use hacky pseudo-encodings.
> _ Marco
Absolutely. A browser should be able to render any language encoded in
Unicode with web fonts, as real Unicode text. There are no technical reasons
why browsers do not do this already (other than that it may be hard to do so
This archive was generated by hypermail 2.1.2 : Thu Jul 04 2002 - 04:56:25 EDT