lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev stopping when viewing a site


From: Leonid Pauzner
Subject: Re: lynx-dev stopping when viewing a site
Date: Fri, 20 Aug 1999 15:56:33 +0400 (MSD)

19-Aug-99 07:27 Klaus Weide wrote:

> Can you remind me what the kludge was good for?  I know that it allows
> to add the tableless charsets in arbitrary order (without pre-filling
> the LYCharSet_UC[MAXCHARSETS] in LYCharSets.c).  Were there any other
> reasons?

Main reason - to clean up the code (so many special cases
will be covered by UCDomap.c only - we could strip LYCharSets.c,
SGML.c, LYCharUtils.c [...] from old entities, PassEightBitRaw etc.
That would be more inlined with current style IMHO).


>> >         ut = UCInfo[UChndl_out].unitable;
>> >         if (ut != UC_current_unitable) {
>>
>> If we change (!isdefault) with (!isdefault && UCInfo[...].unitable != NULL)
>> we will probably bypass all calls to dedicated charset's tables
>> `conv_uni_to_pc(unicode, 0)' so initialization may not be necessary
>> since we only use default table - calls to `conv_uni_to_pc(unicode, 1)'

> That gets ugly, several places to change and to check whether all
> calls to conv_uni_to_pc(unicode, 0) _and_ to UC_con_set_unimap are
> then always skipped...

Well, the only external calls to UCDomap.c stuff are UCTrans* (see UCMap.h)
so it wouldn't be hard to check that places only
(perhaps, an initialization ~UCInit() also).

> The UCInfo[] contains info that only makes sense for character sets that
> actually have chartrans tables.  For the others we don't really need
> any of the stuff that is only put in UCInfo[] but not in LYCharSet_UC[]
> and other LYCharSets.c arrays, except perhaps 'trydefault'.  So we
> should revert to not putting the specially handled charsets[*] into UCInfo[]
> at all, but should create only LYCharSets.c entries for them.  We can
> find a better solution for the ordering problem, if that is the only reason
> for the kludge.  I don't know whether "Transparent" needs to be handled
> specially wrt 'trydefault', or whether all specially handled charsets
> can/should fall back if they get so far (to the UCTrans* functions).

My conclusion about "Tansparent" vs 'trydefault' was based on that fact:
let we have html page with lots of entities like ¥∧&something;
then in transparent mode these entities will have no translation
so we saw them verbatim, instead old behaviour (before my changes)
was based on using 7-bit approximations. IMO CJK behave the same way.

I mean translation "TO charset" e.g. to x-transparent, to any_CJK yes?
(not from ...)

> Please remind me what "Transparent" _should_ do, in your opinion...
> It seems currently "Transparent" is plagued by the same problem as the
> CJK charsets.  Behavior depends on whether it is the first one used.

> [*] With "specially handled charsets" I mean those for which you have added
> macros in UCdomap.h.

>> > PS. Please snip your quotes, don't append quoted patches all the time!

> Ehm, thanks for quoting this, but did you read it? :)

Yes, sure.
(snipping of quotes just a matter of taste based on may factors).

>    Klaus





reply via email to

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