lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Emacs + UTF-8 + Lynx


From: Sergei Pokrovsky
Subject: Re: lynx-dev Emacs + UTF-8 + Lynx
Date: 28 May 2000 13:49:25 +0700
User-agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.6

>>>>> 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:
<address@hidden>:

  Klaus> Note the common pattern: in both cases, the UTF-8 encoding
  Klaus> contains a 0x80 byte.  Possibly this byte value triggers some
  Klaus> error, either in emacs' terminal emulator or in the curses or
  Klaus> slang library your lynx binary is using.  I don't think the
  Klaus> error is in the lynx code, it's hard to see why it would get
  Klaus> just that byte value wrong (and if it's lynx itself, I should
  Klaus> see the error, too.)

  >>  Than I've installed the ncurses, having supplied the ./configure
  >> script with --enable-widec (maybe that was an error?).

  Thomas> no - it's ok.  But the resulting ncurses library is not
  Thomas> compatible with applications that may have been compiled
  Thomas> previously.

OK, I've recompiled xterm.

...

  >> Now the Unicode characters are rendered better in xterm -u8, the
  >> Russian small R no longer misbehaves, I do see em-dash.
  >> 
  >> *But*
  >> 
  >> 1) The fi ligature is rendered as a box in the anchors (see the
  >> anchor

  Thomas> I'll look at this.  I'm not sure whether a box is a
  Thomas> character that does not appear in the font, or if it is a
  Thomas> multi-plane character (requires merging of 2 or more Unicode
  Thomas> values).  There is an experimental patch to handle that, but
  Thomas> I've not integrated it yet (it needs more work).

The problem is gone away after the rebuild.

...

  >> 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.

-- 
Sergei

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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