On Sun, May 28, 2000 at 01:49:25PM +0700, Sergei Pokrovsky wrote:
> >>>>> Thomas Dickey writes:
>
> Thomas> On Sat, May 27, 2000 at 03:17:03PM +0700, Sergei Pokrovsky
> Thomas> wrote:
> ...
> >> The situation is worse with the stand-alone xterm.
> >>
> >> After I've installed xterm, I've got a nice colored display,
> >> which rendered most of UTF-8 almost correctly when called with
> >> -u8 (except for the 0x80 bit bytes mentioned earlier).
>
> Thomas> I didn't notice the mention of the 0x80
>
> Klaus Weide mentioned it on May 26, Message-ID:
> <[EMAIL PROTECTED]>:
>
> Klaus> Note the common pattern: in both cases, the UTF-8 encoding
> Klaus> contains a 0x80 byte. Possibly this byte value triggers some
ok. This is a different context from my changes to ncurses - lynx is
displaying UTF-8 without assuming that the screen library knows about
that. The limitation is that repainting the screen will not necessarily
work, since a code that expands to multiple bytes may match the first
byte or so of the previous (different) code at that location. I think
that's part of what Klaus is referring to.
The only example of using my simple UTF-8 driver is the changes I made
to ncurses' test/view.c, to read a file in UTF-8 format, and redisplay
it using the UTF-8 driver. I think that could be done for Lynx, but
haven't tried it.
> >> 2) Lynx has lost the colors.
>
> Thomas> This is a symptom of the incompatibility that I mentioned.
> Thomas> The bits in a chtype that represent color are shifted by 8
> Thomas> bits. The bold and underlining, etc., also are shifted.
>
> Yes, now this is OK as well.
good. My patch for last night makes libncurses build as libncursesw
for this configuration.
--
Thomas E. Dickey <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
