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: Fri, 26 Feb 1999 13:45:27 +0300 (MSK)

25-Feb-99 22:10 Klaus Weide wrote:
> On Fri, 26 Feb 1999, Leonid Pauzner wrote:
>> 25-Feb-99 07:36 Klaus Weide wrote:
>>
>> > It would be more logical to put "7 Bit Approximations" in the 2nd place
>> > though.  That would change the order in the "Display character set" option
>> > list, but maybe that's not a bad idea anyway.
>>
>> OK, no problem (next time).
>> I would probably suggest moving "7 bit approximation" to the first place
>> (current_char_set = 0) instead. I change lots of such explicit checks
>> with LATIN1 macro, but no guarantee for all places. This is somehow
>> close to the logic of ISO_Latin1 usage...

> Personally I like having ISO-8859-1 always as first item.  Easy to get
> to with the Home key.  And it's still the default if nothing else is
> specified anywhere.  So it should probably stay there.
OK (swapping them temporarily may illuminate some hidden problems on the way)

> LATIN1 should really expand to 0 (or a variable set once at
> initialization), not to UCGetLYhndl_byMIME("iso-8859-1").  Having a
> function call each time this macro gets referenced should be avoided.

Correct, it should not be a function call,
just a variable initialized in LYCharSetDeclare() after UCInit()

>> >> >> @@ -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},
>> >> > [ etc - including CJK, 7-bit approx., transparent ]
>>
>> "*What kind* of CJK encoding" can be mapped to 'enc' value as a region.

> Yes.

>> Check for "160" and "173" can be done dynamically (rare), e.g.
>>   if (160 == UCTransChar(160, from_charset, to_unicode)) {}

> That's another case where I would like to avoid unnecessary function calls,
> instead use the info that's "cached" in a way.  At least that was one reason
> for having bits of info like that in the structures.

The check may be introduced in UCTransParams().
(BTW, cpXXX codepages have NBSP but no SHY ???)

> Whether that's an important consideration depends on how often this check
> has to be done, of course.

Every character >128 being translated via UCTransChar unless we are in raw
mode, not a big win to work with NBSP and SHY in other fashion.

>> Other info can be incorparated into *_uni.h format when necessary.


>    Klaus



reply via email to

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