Re: [Gnome-print] Re: [jody: [ynakai@redhat.com: Re: Gnumeric bug15607]]

[Christopher James Lahey <clahey helixcode com>]

On Thu, 23 Nov 2000, Yukihiro Nakai wrote:

> Unicode(in the future) is good, but utf-8 is very EVIL. Japanese,
> Chinese and Taiwanese(Chinese in Taiwan) use many same characters in
> different glyphs. But utf-8 ignores that. Utf-8 maps one character in
> one glyph. So utf-8 ignores and breaks our each culture, that's the
> point. Japanese and English may be in one utf-8 document, but Japanese
> and Chinese can't be in one utf-8 document. Please don't think utf-8
> is complete.
> 
> Even if utf-8 becomes to be a standard in Linux/Unix, we'll still use
> lang-depend utf-8 locale. Such as ja_JP.UTF-8, zh_CN.UTF-8,
> zh_TW.UTF-8.

We absolutely know this.  You'll need to have different fonts depending
on the 

> There should be a mime header including charset in documents, and
> applications should see that.

No, the charset should always be utf8.  What the documents should specify
(IMO) is the language that the text is in.  This would determine which
type of characters were used.

> We know we should move to the Unicode world with utf-8 locales ASAP,
> but can never move so soon as single people do. There is many many
> non-GNOME apps and system in our Linux distro and Linux box , and
> almost of all are still not ready for utf-8. It will take more than 2
> or 3 years for us to be ready for utf-8, but we can't use GNOME until
> that if GNOME is such too optimized to utf-8. People will not use
> GNOME, and also Linux for years!

We should be able to make UTF8 work internally even if your locale is set
to something else and your font uses a different charset.

> I think it's one of the good feature that all new and old can co-exist
> in GNOME. We can see, create and remove files from legacy terminals
> with legacy command, also from gmc. They don't conflict.
> 
> So, we don't want you to ignore our legacy locales/encoding at least
> more 2 or 3 years...

It's not an issue of ignoring them so much as working with them
externally, while using UTF8 internally.

Thanks,
    Chris