From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10108071658.AA17159@clio.rice.edu> Subject: Re: gettext port To: djgpp-workers AT delorie DOT com Date: Tue, 7 Aug 2001 11:58:29 -0500 (CDT) Cc: salvador AT inti DOT gov DOT ar (salvador), ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De (Juan Manuel Guerrero) In-Reply-To: from "Eli Zaretskii" at Aug 07, 2001 10:56:46 AM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > The bloat in libiconv is not because of Unicode, it's because all the > tables are compiled into the code instead of being read from a file. > If someone modifies libiconv to read the tables from files, the bloat > will go away, and you get the bonus of being able to distribute only > those encodings that matter. The way libiconv is written it would be a major effort to get it to read from files. It does look like the tables (and some of the custom lookup code which goes with each) could be moved to a loadable module with a few ifdefs. If someone wanted a different (smaller or enhanced) set the loadable module could be changed. This is just a quick analysis from a architecture point of view - I am not familiar on how the routines are typically used to know if this helps at all (except for saving 600Kb out of each image). For example, if the loadable module or certain disk files were missing is there a smart default on what to do?