lynx-dev
[Top][All Lists]
Advanced

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

Re: [Lynx-dev] real woes: lynx2.8.6dev.7, OR ncursesw, OR japanese-utf8


From: Thomas Dickey
Subject: Re: [Lynx-dev] real woes: lynx2.8.6dev.7, OR ncursesw, OR japanese-utf8
Date: Mon, 8 Nov 2004 05:31:38 -0500 (EST)

On Mon, 8 Nov 2004, Atsuhito KOHDA wrote:

> From: Thomas Dickey <address@hidden>
> Subject: Re: [Lynx-dev] real woes: lynx2.8.6dev.7, OR ncursesw, OR 
> japanese-utf8
> Date: Sun, 7 Nov 2004 16:55:02 -0500
>
> > Recall that he
> > made an executable which I tested and didn't see the problem.
>
> Well, I had posted an email to a Debian's mailing list
> in Japan to ask if anyone would see the problem with my
> executable and got two replies which told me that they saw
> the same problem as I saw and couldn't find any settings
> nor options with which lynx rendered a page correctly.

I might be testing too simple a case - one of my recent ncursesw fixes
was for a case where repainting would not account for all of the cells
of a multicolumn character.  This was after your report and my testing,
but it was one of the odd cases which does not happen all the time:

20041023
        + revise storage of cells for multi-column characters to correct a
          problem with repainting.  In the old scheme, it was possible for
          doupdate() to decide that only part of a multi-column character
          should be repainted since the filler cells stored only an attribute
          to denote them as fillers, rather than the character value and the
          attribute.

This showed up in some editing of input strings - I haven't encountered it
in a scenario such as the lynx link-highlighting.  But in combination with
some other problem (unknown), it may affect output.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net




reply via email to

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