Mail Archives: djgpp-workers/2001/08/06/14:13:10
Juan Manuel Guerrero wrote:
> The codepage used by libiconv.a is read ones and can not be changed while the program
> is running.
Can I disable the use of libiconv.a? I want to: (a) avoid innecesary translations and (b) avoid binary bloat.
Can I force gettext to avoid conversions?
I ask it because my text editor can switch code pages on the fly (and if you are in a DOS console with text mode you
can ask the editor to create and load the appropiate font).
[snip]
> This is certainly true but the argument does not hold for NLS, IMHO. We do not need runtime
> recoding at all, IMHO. We know *apriori* what msdos codepage does exist for that particular
> language and country. *No* other dos codepage can be used to display that messages.
That's not true, but the idea is ok. Let me clarify: a lot of people loads an incorrect code page or just a custom
one. So it isn't true. The cyrilic code pages pointed out by Eli are a good example, not all russian people uses the
CP866 (I don't remmeber if that's the right number). Some uses KOI8 (not an ANSI/IBM/M$ code page). But is also true
that people use to make some small changes to the code page. In fact the same happends under Linux, the supposed
ISO code pages fills the undefined values with anything. The point is: it is not true that we know what the user
have, but is also true that libiconv won't help much with it.
If we know the common cyrillic code pages are three or four we can include 3 or 4 versions of the file and put them
in a separated zip (in fact all the .mo files could be optional, in a separated .zip).
My *personal* point of view is that libiconv doesn't help much and we should have a mechanism to at least disable
it. I don't say remove it at all because perhaps some program could be benefited from it.
BTW: Why the library have the code pages in the binary? Is because of shared libraries limitations?
Why code pages aren't in disk, lets say in /usr/share/codepages and the library loads only the needed one and shares
it with other instances of the library? Isn't it possible? I don't know much about the limitations of shared memory
and dynamic libraries.
[snip]
> This is the usual way this codepages are coded, ascii is always available in the first 127 chars,
Just a comment: 32 to 127. Under 32 the symbols aren't defined by standards because those are control codes.
[snip]
> Last but not least, I have reconfigured and recompiled gettext-0.10.39 but this time without
> libiconv. Of course all .po files have been recoded apriori using the recode program so runtime
> recoding via build-in libiconv is not needed anymore. A comparation between xgettext.exe from
> gtxt039b.zip and the newone shows:
> xgettext.exe with libiconv (from the port available at simtel): 689648 bytes
> xgettext.exe without libiconv (newone): 72480 bytes
8-)
[snip]
> In conclusion:
> 1) It is not my intension to start an useless and prolongated discussion about the use
> or the discard of libiconv.a. In view of the amount of inconvenieces (amount of work
> that is needed to get working configure scripts (gettext.m4 issue) and the huge size
> of the produced binaries) and the limited benefits, there is no justification for the
> use of runtime recoding (libiconv.a) at all, IMHO. The quality of the message output
> of an NLS binary is limited by the existance of appropiate dos codepages. The actualy
> existing codepages are defined in charset.alias. This table is identical to the table
> I have used in gtxt035b.zip to recode .po files at configuration time using the recode
> program. It is realy quite simple: .po files that can not be recoded during configuration
> also can not be recoded at runtime. If this is the case, runtime recoding seems superflous.
Just an idea:
What about writing a replacement for libiconv? A simple library that loads a table from disk (using some environment
variables to select the file) and does a simple 1 to 1 conversion (not unicode). The conversion could be in the
mentioned file with two columns (convert A into B). We could provide the most common DOS conversion maps and the
user write their owns.
This library (unlike libiconv) could be:
1) Fast.
2) Small.
And could solve our problems
SET
--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft AT bigfoot DOT com set AT computer DOT org
set AT ieee DOT org
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
- Raw text -