On Mon, 24 Apr 2006 11:44:56 +0330
"roozbeh gholizadeh" <[EMAIL PROTECTED]> wrote:
> On Sun, 23 Apr 2006 23:42:14 +0330, Mattias Gaertner
> <[EMAIL PROTECTED]> wrote:
>
> >> Is there such a thing?
> >> and if not,any plans for this?
> >
> > First of all: 'unicode' is merely a table. The computer needs an
> > encoding.
> > The LCL supports UTF-8. So, yes, there is already a unicode LCL.
> > Probably you want UTF-16 for wince.
> >
>
> Well i didnt get this?
> Delphi VCL also supports utf-8 and also utf-16 and utf-32 and utf-7 but it
> doesnt make it unicode vcl.
> check delphi newsgroup and see how peaple are demanding this for
> years.(and it seems to be ready in delphi 2007).
>
> All functions and procedures in lcl use ansistring,i dont think for
> label.caption := 'something' converting it from ansi to wide is always a
> good idea.
> I mean we have a lcl that label.caption is itself a property which reads
> and writes in widestring,also lazarus saves all strings in forms as
> unicode instead of ansi,thats the true unicode engine,just converting
> doesnt make sense,also with ansistring you can have just one local
> langauge,how can we have a label.caption which some part of its text is in
>
> russian,persian,english,japanese?
> this is only solved by true unicode lcl.
I still got the feeling, you think 'AnsiString' can not be UTF-8.
More clear:
UTF-8 is an 8bit encoding for the whole Unicode set.
So russian, persian, english, japanese, arabic and klingon can be all in one
UTF-8 AnsiString.
Don't let you confuse by the pascal name 'AnsiString'. It is not Ansi, just
8-bit characters.
About Delphi and newsgroups:
Please take a closer look and tell concrete problems.
The current unicode problems of the LCL are:
- missing bidi in synedit (it has been started, but not finished)
- many gtk1 fonts are non unicode fonts
- many fonts are limited to a few languages. You have to search for fonts,
that support russian, persian, english, japanese, arabic and chinese.
- keyboard: This is not an unicode problem, but it relates: synedit does not
translate special language keys. E.g. french accents.
> >> Becouse while i was trying to make wince interfaces work,i see lots of
> >> convertion to unicode,and it really makes these interfaces slow,which
> >by > the fact that all wince devices are rather slow,makes them
> >inefficient. >
> >> For example it is really pointless converting every tstrings to unicode
> >> when some actions to winceapi is required and so on.
> >
> > For TStrings the overhead is indeed high, although O(n).
> > Do you have some ideas how to reduce the overhead?
> >
> Well i think creating a twidestring and twidestringlist is what we need.
> Also converting from unicode to ansi isnt what we can think as solution
> becouse in this conversion we lose datas!so it is not an approach,it's
> just pretending that we solved it.
We don't loose data. See the UTF-8 functions in the LCLProc unit.
> I have a unit which implements twidestring,and twidestringlist and also
> has a very decent speed,i think it is licensed under gpl,and i bet there
> are lots of other implementations that do this,maybe we can use them.
GPL is not enough for the LCL.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
