On Fri, 2003-02-21 at 12:47, Kean Johnston wrote:
> > There's a "libcharset" that I think comes with libiconv and
> > is also used in GLib that you can use to work around this problem.
> Which is fine if you use GNU iconv. For those of us that use
> the iconv as it was originally invented, libcharset doesn't
> seem to help very much. Maybe I am missing what its trying to do
> but certainly on Unixware and OpenServer, it does nothing of
> any use.
>
> The way I got around this on OpenServer was (I think) rather
> sneaky. Our iconv() lets you add in a .so for any given encoding.
> So I added the ability to define in the iconv data file a fallback
> mechanism ... basically * * for the "from to" fields. Then I simply
> put the whole of GNU iconv in under that entry. So our system
> defined conversions are used first, and for all those Linux-centric
> applications that are so badly written to really only support one
> OS now "just work".
Note that iconv as "originally invented" is ENTIRELY BROKEN because
no list of standardized encoding names was specified and no
set of encodings was required.
I don't know what politics or technical oversight was behind this,
but it means that using iconv() portably is impossible without
extra infrastructure.
The GLib library (used by GTK+, GNOME, etc) works around this
by using the libcharset data in both directions ... as well as
getting a standardized form of encodings reported by the operating
system, it will use it convert standardized names into names that
are likely to work for iconv() on a particular system.
Regards,
Owen
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
