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

List:       kde-core-devel
Subject:    Re: KDE2 actually doesn't support Unicode
From:       Matthias Ettrich <ettrich () troll ! no>
Date:       1999-12-21 1:19:20
[Download RAW message or body]


The following answer is from Warwick Allison <warwick@troll.no>, he's not on the
kde-devel list right now, but I will forward the interesting stuff.

Matthias

--------------------

[snip]

>
> To overcome this limitation, I think we
> have to flee in forward direction. Everywhere, where
> it makes sence, we should *actually* support
> Unicode. The essential points are the following:
>
> 1. It should be possible to save and read documents
>    as UTF-8/UCS-2. This affects applications like
>    KEdit, KWrite, KWord, KSpread, but graffic and
>    other applications too. Think about a multilanguage
>    poster, presentation, email a.s.o.
>

Files with "proprietary" binary formats can write QString's dara directly
(UTF-16), if they for example use QDataStream.

>
> 2. All interapplication protocols dealing with text
>    should understand UTF-8 and/or UCS-2 (clipboard, drag&drop, MIME...).
>    May be this works at the moment, if there are used Qt classes,
>    otherwise may be not.
>    Some Internet applications are already UTF-8 aware, thats ok.
>

Qt drag-and-drop and clipboard uses "text/plain" (ie. locale-specific
encoding), "text/plain;charset=utf8" (ie. UTF-8 encoded Unicode) as two of
the MIME types always offered for text. It also offers XA_STRING format
(same as "text/plain". When QTextDrag is used, there should be no problems.

>
> 3. There has to be an abilty to input characters of different
>    languages with the keyboard. In KDE 1.x I could use
>    Kikbd for this. This doesn't work now in KDE 1.89,
>    because Qt converts any character coming from the
>    XServer to Unicode with this "CodecForLocale", so
>    I limited to my default language settings ones more.
>    (An input method by a graffical character table is useable
>    only for some special character but not for different
>    languages).
>
>                     * * *
>

Sensible.  It's what MS does.

>
> I think, if the important text applications KEdit,
> KWrite, KWord, KMail could import and export UTF-8 and
> I had a facility for putting Unicode characters with
> the keyboard into a document, this should be enough
> for KDE 2.0. More Unicode support could follow in small steps
> in the releases after 2.0
>
> Trying to note, what should be done for such a minimal support:
>
> a) For fileimport/-export most suitable in my opinion
> would be an option in the file dialogs. If the applications
> uses the Qt standard classes for saving and reading files,
> such as QTextStream, or the derived classes such as KFile,
> it's enough to change the codec, when this option is set.
> (e.g. if (saveAsUTF8) file.textStream()->setCodec(
>  QTextCodec::codecForName("utf-8")); )
> If the standard classes aren't used, it will be some more work
> for the developper.
>
> b) In order to input characters with the keyboard,
> first we need a Qt API function to change the variable
> application_x11.cpp:input_mapper. The bigger task
> is an application, which makes it possible to create
> keyboard layouts and to change the keyboard layout
> while typing a text.
>
> I don't know, if we have to write this from the scratch
> or if we could modify Kikbd, which now manipulates the
> XServer, not the manner Qt interpretes keyevents.
>
> Ok, it was easy for me to write down the wishes from
> a KDE users point of view. As a KDE developer it
> may be difficult not to forget that some Unicode
> stuff while learning to deal with this many new
> concepts like Corba, DCOP, XML...
> For Windows NT it took 4 years to bring the internal
> Unicode implementation to the user interface.
> I think we should do this in KDE within the next
> 4 months :)
>
>   Wolfram.
>
> --
> Wolfram Diestel <wolfram@steloj.de> http://www.steloj.de/

The only really difficult task is fonts. Qt does not do any "clever" mixing
of fonts, as Qt is not the place for that. A user who seriously wants
multiple language support should have a UTF-8 locale, and unicode fonts
(preferably in iso10646 format). Font servers are only just now becoming
useful for such large font sets (but with XFree86 moving towards Unicode,
this has heaps of room for improvement).

My suggestion is not to try too hard for the "everyone can read and write
every document" goal. Go for the initial goal "those who choose to can read
and write every document; everyone else can read and write one language in
documents". This is basically what Qt supports: you can use Unicode to the
fullest, IF YOU CHOOSE. But since many people just want to continue with
their locales, let them - but make sure they can communicate documents with
people who are needing full Unicode support.

--
Warwick

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