Date: Wed, 1 Aug 2001 11:34:05 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: JT Williams cc: djgpp-workers AT delorie DOT com, tim DOT van DOT holder AT pandora DOT be Subject: Re: gettext port In-Reply-To: <20010731175058.A1259@kendall.sfbr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 31 Jul 2001, JT Williams wrote: > -: > 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. > > Thanks, Tim. That's exactly the kind of arrangement I would > have expected, and I agree completely with your assessment. You should probably discuss this with the gettext maintainer. Who knows, perhaps he will change the design, or maybe some option to do this already exists?