lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev cleanup chartrans [patch]


From: Leonid Pauzner
Subject: Re: lynx-dev cleanup chartrans [patch]
Date: Thu, 25 Feb 1999 14:45:19 +0300 (MSK)

25-Feb-99 04:49 Klaus Weide wrote:
> On Thu, 25 Feb 1999, Leonid Pauzner wrote:

>> An attempt made to remove old-style charset declaration
>> in favour of chartrans-style. Few comments corrected.
>> Futher cleanups appreciated.
>>[snip]
>> * Chartrans: old-style declarations of charsets which do not have Unicode
>>   tables (CJK, x-transparent, also UTF-8) now moved from LYCharSets.c to
>>   UCdomap.h and now included with UCInit() in UCdomap.c in a standard way.

> I am a bit skeptical about this patch.  Maybe it's just me not being able
> to throw anything away.  So I leave the decision to someone else.  But
> consider the comments below.

>> @@ -329,20 +332,6 @@
>>  PUBLIC CONST char ** LYCharSets[MAXCHARSETS]={
>>         ISO_Latin1,             /* ISO Latin 1          */
>>         SevenBitApproximations, /* ISO 8859-15 (Latin 9)*/

That is an example on "SevenBitApproximations" usage,
we couldn't go any further with UCdomap.c "new method meets old method!"
cleanups if we remove this reference to SevenBitApproximations.
I mean this is not the last step in cleaning up things,
ISO_Latin1 may be the next :-)

> What's special about 8859-15, to be the only one left intact here
> besides 8859-1?  "7 Bit Approximations" would much rather deserve that
> honor.
Well, yes, but this got hidden the another side...

>> -       SevenBitApproximations, /* DosLatin1 (cp850)    */
>> -       SevenBitApproximations, /* WinLatin1 (cp1252)   */
> [ ... ]
>> @@ -394,41 +369,6 @@
>>     *  Placeholders for Unicode tables. - FM
>>     */
>>    {-1,"iso-8859-15",   UCT_ENC_8BIT,0,0,0,     UCT_R_8BIT,UCT_R_ASCII},
>> -  {-1,"cp850",         UCT_ENC_8BIT,0,
>> -                       UCT_REP_SUPERSETOF_LAT1,
>> -                       0,                      UCT_R_8BIT,UCT_R_ASCII},
>> -  {-1,"windows-1252",  UCT_ENC_8BIT,0,
>> -                       UCT_REP_SUPERSETOF_LAT1,
>> -                       0,                      UCT_R_8BIT,UCT_R_ASCII},
>> -  {-1,"cp437",         UCT_ENC_8BIT,0,0,0,     UCT_R_8BIT,UCT_R_ASCII},
> [ etc - including CJK, 7-bit approx., transparent ]

> The various tables here served to provide some minimal information
> (without taking much space) about several charsets / Display character
> sets even in the case where chartrans table files for them were not
> included.  Yes it's redundant; however, sometimes redundancy *may* be
> good.
Yes, but in this case I think this redundancy may be misguiding for other
changes. In fact, no fields from this struct are used except mime name and
encoding name, only UCT_REP_* _may_ be useful when we are very close to
old-style LATIN1 charset.

> Historically, that information was first listed here because
> EXP_CHARTRANS was optional; later, because for quite some time not all
> of the Display character sets traditionally handled by Lynx had
> associated .tbl files (not just the CJK ones).  I always kept thinking
> that whoever installs Lynx should be able to exclude most (or all) of
This is still possible based on chrtrans/README.tables, isn't it?
And if someone considered seriously on removing 7-bit approximations file
what we could benefit for him, anyone tested? It may be probably safer to edit
entities.h and exclude most entries except ISO LATIN1 instead.

> the chartrans files, and still have some minimal fallback behavior in
> that case, at least as good as say Lynx 2.6.  I am not sure this is
> still the case; maybe it's not wanted.  It probably hasn't been tested
> by anyone in a long time.  An example would be the case where someone
> wanted to not have the large 7-bit approximations file, but still have
> 7-bit approximations available as Display character set to at least
> deal with the "classical" ISO-8859-1 chars and entities.
How about Euro/(TM)/Copyright/emdash/etc requests?

> Well, since even Henry seems to not have tried that, it may be
> irrelevant.  It could become relevant if one day configure allowed
> to specify the to-be-included chartrans .tbl files.
No problem, except the default table.

>    Klaus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]