[Lazarus] rewriting of LConvEncoding

[merlin352 at globe.lu]

--- Ursprüngliche Nachricht ---
Von: Michael Van Canneyt <michael at freepascal.org>
An: Lazarus mailing list <lazarus at lists.lazarus.freepascal.org>
Betreff: Re: [Lazarus] rewriting of LConvEncoding

> On Mon, 20 Sep 2010, merlin352 at globe.lu wrote:
>
> >
> > --- Ursprüngliche Nachricht ---
> > Von: Mattias Gaertner <nc-gaertnma at netcologne.de>
> > An: lazarus at lists.lazarus.freepascal.org
> > Betreff: Re: [Lazarus] rewriting of LConvEncoding
> >
> >> On Mon, 20 Sep 2010 20:51:20 +0200
> >> <merlin352 at globe.lu> wrote:
> >>
> >>> Hello
> >>>
> >>> I had some issues with LConvEncoding as I wrote in
> bugtracker issue
> >> #0017212
> >>>
> >>> My mistake was essentially the meaning of character
> encoding
> >> "ANSI". Sorry for that.
> >>>
> >>> So I took a deeper view at this unit. It is far not
> complete
> >> concerning existing codepages and support for Unicode.
> >>
> >> It's goal is to convert the most common codepages and do the
> >> rest with the existing OS libraries (iconv).
> >>
> >> A complete conversion unit should be part of FPC.
> >
> > I agree, but that should be decided by the core developers.
>
> The core developers do not have a problem with this.
> Since it is mostly tables anyway, I see no reason not to do it.
>
> Note that FPC does contain a some conversion code in the RTL,
> see the ucmaps directory and the charset unit.
>
> Michae--

The files in ucmaps are the files from ftp.unicode.org that I mentionned.

My opinion is that static tables are smaller and faster than dynamic mappings (especially for the asiancodepages), but memory could be an issue. Perhaps this can be solved by smartlinking.



______________________________________________________
powered by GLOBER.LU
Luxembourg Internet Service Provider
Hosting. Domain Registration, Webshops, Webdesign, FreeMail ...

Our professional Web Hosting plans include all the features you are looking for at the best possible price.
www.globe.lu