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
