Michael Jansson wrote:
> 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. [...]
OK, that's a good reason for having a workable web font technology.
(Although Swedish is a poor example, as it uses the same "Western Latin"
subset used for English.)
This issue is even more important in emerging countries, where people often
do not own the computer they work on.
> Take Polynesian languages for example, e.g. Hawaiian. [...]
Curiously, Hawaiian could be supported by the "Baltic Latin" subset
(http://czyborra.com/charsets/iso8859.html#ISO-8859-4 -- although I guess
they'd have some problems interpreting menus in Estonian or Latvian. :-)
> 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.
Why!? These proprietary "encoding" schemes often have serious functional and
compatibility problems, so the way to go is trying to wipe them out of
history as soon as possible.
In principle, Unicode support is not rocket science, and does not
necessarily have to be at the OS level. Browsers for older OS's can
implement Unicode themselves, using libraries such as ICU.
The really hard part (but only for some scripts) is text display and the
poor font coverage for some scripts. In this area, web fonts can play a big
role, provided that they have all the needed functionality, or that the
browser supplements the missing functionality (as opposed to the author
supplementing the missing functionality).
> 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.
Agreed. I think web font technology may take two alternative roads:
1) Trying to match (part of) the "complex script" functionality offered by
modern font technologies (OpenType or its competitors);
2) Defining a standard glyph code and a standard glyphization process for
Unicode. The client should then be required to run this glyphization process
behind the scenes, and then to load glyphs from fonts using the standard
glyph codes.
Approach 1 is much more flexible, but approach 2 is easier to implement and
requires less data in the fonts.
In both cases, web documents should be encoded only with Unicode or other
standard encodings, not with codes referring to glyphs in a particular font.
_ Marco
This archive was generated by hypermail 2.1.2 : Thu Jul 04 2002 - 05:46:15 EDT