Mail Archives: djgpp-workers/2001/07/31/16:24:52
> > Surely NLS support is a good thing, but I really was shocked at the
> > resulting increase in size of the NLS-capable executable. E.g.,
> > sed 3.02.80 with NLS support---even stripped and UPX-compressed---is
> > seven times larger than the corresponding 3.02 executable! I naively
> > expected NLS support to involve a few hooks in the application itself,
> > with the real nuts and bolts---and code overhead---of the support to
> > reside elswhere (e.g., an optional app).
>
> NLS support requires translation between different character sets,
> like between ISO-8859-1 and the corresponding DOS codepage 850 (to
> pick an example that is relevant for DJGPP). Each such conversion
> requires 2 tables: from the source charset to Unicode and from Unicode
> to the target charset. Taking into consideration how many charsets
> are supported, you can imagine the sheer volume of the tables this
> requires. All of those tables are sitting inside the program.
Exactly - I consider this a bad design decision, coming from the
standpoint 'It's a shared library anyway', which simply doesn't hold
true on all platforms (even though libiconv's configure.in tries to
disable static builds IIRC). It seems to make much more sense to have
data files in $prefix/share/iconv, with only those tables that are
actually required loaded into memory. If none are found (as would be
the case on systems without libiconv installed), this would mean no
charset translation was possible, but that is a small drawback
compared to wasting several megabytes of disk space.
- Raw text -