[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [otaylor@redhat.com: .desktop files and encodings]
From:       Lars Knoll <lars () trolltech ! com>
Date:       2001-03-01 10:02:04
[Download RAW message or body]

On Thursday 01 March 2001 02:51, Keith Packard wrote:
> Around 22 o'clock on Feb 28, David Faure wrote:
> > > You guys clearly haven't been involved in the XFree86 i18n wars.  The
> > > JIS users will resist assimilation for as long as possible...
> >
> > Hmm, the fact that a desktop files uses UTF-8 doesn't mean that
> > the user has to enter anything in UTF-8 himself.
> > Translators have proper tools for that (kbabel), and the user sees
> > the string in his language (obviously :) - I mean, even if he doesn't
> > have UTF-8 fonts.
>
> The essential argument is that UTF-8 is insufficient for encoding han
> documents, especially those requiring multi-lingual support including
> Chinese, Japanese and Korean.  This would make it inappropriate for
> any file that might contain han characters.

Because of character unification in Unicode. I've followed the discussions on 
the xfree i18n list for a while, still I think they are exagerrating. I'd 
very much prefer adding some sort of language tagging to a utf8 encoded 
string than using iso2022
>
> ISO 2022 is preferred, as that spec allows embedding multiple local
> encodings within a larger structure.

Using iso2022 would be a _real_ mess to support everywhere. Looking at the 
windows world, I don't really see a reason not to use Unicode. They do the 
same and probably add some sort of language tagging for glyph variants. 

At least the documents stay readable for asian users even if you sometimes 
get a wrong glyph variant for some character. 
I agree, that this might be annoying, but I don't really see a way to support 
iso2022 everywhere. Having to deal with iso2022 encoded strings is almost 
impossible for most application developers and would only lead to people 
falling back to developing latin1 only apps.

> You'll note that even C99 doesn't specify ISO 10646 for wchar_t, instead
> requiring applications remain neutral to the encoding for each locale. And
> the BSDies are headed into na-na land by using a non-10646 wchar_t for most
> asian locales in their implementation.

But Qt/KDE uses string, which is defined as being a unicode string. KDE-2 
doesn't support mixing of different asian locales anyway (except when using 
unicode fonts). It'll get possible when we switch to Qt-3, but implementing 
support for mixing of different glyph variants is a real horror, and I don't 
feel like going that way. We'll probably keep the current way we have in 
Qt-3 which is choosing glyph variants (or fonts) based on locale.

> A lot of this has roots in the original 16-bit Unicode spec, which was
> clearly insufficient, and the NIH attitude taken by the JIS encoding
> community.

NIH?

> I think you should use UTF-8 and let the JIS users implement their own
> house of horrors based in ISO 2022, but you may need asbestos suits...

Let's see if they do. Up to now I got the impression that the asian KDE 
community was quite happy with unicode.

Cheers,
Lars

[prev in list] [next in list] [prev in thread] [next in thread]