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

List:       koffice-devel
Subject:    Re: Fwd: Re: Fwd: Re: Questions about Kpresenter's Find,
From:       Lars Knoll <lars () trolltech ! com>
Date:       2004-11-20 14:54:58
Message-ID: 200411201554.58684.lars () trolltech ! com
[Download RAW message or body]

On Saturday 20 November 2004 09:08, Nicolas Goutte wrote:
> Are sure that it is what he has meant?
>
> I have more understood it as being the basic Latin character and its
> accents, which as far as I (littlely) know Vietnamese uses.
>
> So there are two ways for an accented character like:
>  é
> or
>  e'
> (Of course unlike in this email, the correct accent is not a normal quote,
> but a special character. As far as I know, it is called "Combining
> Diacritical Marks" in Unicode terminology, characters U+0300 and following:
> http://www.unicode.org/charts/PDF/U0300.pdf)
>
> So if you search one form, I suppose that you will not find the other form.
> (The same problem could appear in many Western European languages, except
> that the forms character + accent does not need to be used, as anyway all
> characters exist in the corresponding ISO-8859 encodings and therefore in
> UTF-8.)
>
> So personally I fail to see what it would have to do with Chinese in this
> case. I suppose that the answer was about how to code with a "surrogate
> pair" in UTF-16 characters that characters that do not fit in 16bits.
> (UTF-8 and UTF-32 do not have this problem.)

Well, I may have misunderstood him, but usually when someone talks about one 
character being composed of to 16 bit values they mean Unicode outside the 
BMP in utf16.

> (As Qt declare using ISO-10646-UCS2, it does not even need to support
> "surrogate pairs" , as, as far as I know, it is the main difference between
> UTF-16 and UCS-2.)

We've got some requests for handling of utf16 and have added support for it to 
codecs and QSttring::from/toUtf8(). We still declare it to be ucs2 to not 
break applications relying on that name.

As to combining marks: Rendering and handling them should work fine. The only 
thing that does not work in Qt 3 is searching for one form and finding the 
other (although there is a rather slow hack to do it: decompose both strings 
using QChar::decomposition() before you start the search).

Qt 4 has support for unicode normalization forms, so this should be much less 
of a problem there.

Cheers,
Lars

>
> Have a nice day!
>
> On Friday 19 November 2004 10:57, David Faure wrote:
> > ----------  Forwarded Message  ----------
> >
> > Subject: Re: Fwd: Re: Questions about Kpresenter's Find, Replace
> > functions Date: Friday 19 November 2004 10:45
> > From: Lars Knoll <lars@trolltech.com>
> > To: David Faure <faure@kde.org>
> >
> > He's talking about utf16. Qt 3.3 does support utf16 partly (string
> > handling is mostly there, rendering is untested). This support is mainly
> > interesting for chinese people. Give me a font that has characters there
> > (I don't have one currently) and a text encoded in utf8, utf16 or gb18030
> > and I can see what can be done for 3.3.4.
> >
> > Cheers,
> > Lars
> >
> > -------------------------------------------------------
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]