If you install Outlook Express with IE5 and receive a message in Chinese,
Japanese or Arabic etc. the application prompts you to install the necessary
support - and if you click O.K. it will download the necessary files and
fonts from the net and install them. I'm not sure if this also happens when
a user without one of these languages installed hits a web page in that
language / script - but this behaviour seems like a good solution. Even if
you don't choose to download and install the language pack at least you know
why you can't display the characters properly and you are told which
language the message or page was written in.
(Huge "Unicode" fonts don't seem like a viable solution even with the large
hard disks and amounts of memory supplied on new PC's. Arial Unicode, which
ships with Office 2000 is 23.5Mb.)
Addison P. Phillips <email@example.com> wrote:
> Hi Ed,
> I'm aware of these nice multilingual features in these products. Thanks
> pointing them out again, though.
> However, if you are authoring web pages for a general audience, then IE
> NN are the standards you have to support. My point is: just because you,
> the page author, can view the character does not mean that arbitrary users
> can view it. Users on most standard installs of Windows, Mac, or UNIX do
> not get the character sets and fonts by default and most won't understand
> why that little black square is being presented in place of various
> (sometimes common) characters.
> IOW: I'd argue in favor of more Unicode and cross-script support built
> the operating systems. I would be happier if, for example, the retail
> Windows 2000 included the full install of all of the scripts and
> fonts by default. My understanding is that this won't happen for obvious
> reasons: most users don't need it and don't want to buy a larger hard disk
> (I'm happy that they will be installable by people like myself who would
> like to type the occasional Japanese without rebooting, though).
> In the meantime, Web developers need to be aware of the "standard" level
> support (which means code page support, for example, on Windows) in order
> to get the result that they expect. And realize that while NCRs may encode
> the data in a lossless manner, the end user will probably see a question
> mark, underscore or black block at display time.
> Someone might argue that characters that you can't display are probably as
> meaningful as displaying characters the user can't read... but in most
> cases I find that users read that your page is "broken" somehow.
> Addison P. Phillips
> Senior Globalization Consultant
> Global Sight Corporation
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT