Re: lynx-dev Lynx character entity references fix

[Klaus Weide]

On Tue, 9 Mar 1999, Leonid Pauzner wrote:
> 9-Mar-99 12:45 Klaus Weide wrote:
> > Among the previous changes (that are in dev.18/dev.19), the following
> > looks wrong.  In UC_con_set_trans():
> 
> >     for (i = 0; i < UCInfo[UC_charset_in_hndl].num_n256; i++) {
> >         if ((j = UCInfo[UC_charset_in_hndl].unicount[i])) {
> >             ptrans[i] = *p;
> >             for (; j; j--) {
> >                 p++;
> >             }
> >         } else {
> >             ptrans[i] = 0xfffd;
> >         }
> >     }
> 
> > Here ptrans points to one of the four tables (slots) in translations[].
> > Your change leaves the table unchanged when it should be re-initialized.
> > So (to-Unicode translation for) one charset could effectively inherit
> > the translations for a completely different charset that used the same slot
> > before.
> 
> Yes, I was not able to understand why we have four tables
> (IMO only one is really used) and what is UC_MapGN for.

Efficiency - saves table initialization time when moving between documents
with different charsets.  Only applies to the "forward" (to Unicode)
tables.  But this should be the most likely kind of switching that occurs
(under the simplifying assumptions that "forward" translation occurs only from
the document charset and from-Unicode translation occurs ony to the Display
character set, and that changing the Display character set is not a frequent
event).

Not invented by me, taken from the original linux code.

> So I just "add" num_n256 so things works without index overrun
> (and hopefully with a proper result) and postpone more UCDomap.c changes
> for dev.Next - patch from your side really welcome :-)

Are changes necessary, and for what purpose?

Most of UCdomap.c is the inner engine of the chartrans code, while it may
not be very clear, it has done its job faithfully with minimal changes over
several versions.

I am inclined to say, mess with it at your own risk...

> > The closer equivalent to previous behavior would be to initialize all 256
> > elements to 0xfffd.

And that could be easily restored.

   Klaus