[Top][All Lists]

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

Re: lynx-dev UTF-8 display questions (was: Superscripts)

From: Sergei Pokrovsky
Subject: Re: lynx-dev UTF-8 display questions (was: Superscripts)
Date: 15 Jun 2000 12:45:36 +0700
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6

>>>>> Klaus Weide writes:


  Klaus> In the meantime, I have found _another_ problem which I can
  Klaus> see in 2.8.3rel.1 with slang 1.3.9.  This time, it appears to
  Klaus> be a real bug in the lynx code (as opposed to: imperfect
  Klaus> workaround for UTF-8-unaware display library).  Let me try to
  Klaus> describe this, it's rather strange, I wonder if you can
  Klaus> reproduce it.

Yes, I can.  And even for a non-Unicode page:
<> is a Latin-1
version of the same document.

  Klaus> This does not depend on -show_cursor, -nocolor, or link
  Klaus> numbering.  Your window size should be 80x25,


  Klaus> lynx User Mode == Advanced.

same for Intermediate

  Klaus>  Start lynx on
  Klaus>, in an xterm
  Klaus> -u8 (with lynx's display character set as UTF-8, of course).

I can reproduce it in Solaris' console without -u8 and for the
Latin-1, as I've said above.

  Klaus> 3.) Now back in AL.html, move around among those 4 links.
  Klaus> This time, the horizontal position of the current link (other
  Klaus> than the first) is consistently wrong, shifted to the left.

Yes.  Though the behavior is not quite consistent.  Sometimes just the
second anchor is shifted, sometimes all those passed.  And first I see
a (?) character, which disappears later.

Actually what I see for the Latin-1 is this:

The original

|  Sekvan pagxon! Antaùan pagxon! Indekson! Instrukcion!

after a visit to Options and four -> is replaced with

|  Sekvan pagxon! Antaùan pagxon#Indekson!#Instrukcion!!

where # (that's what it becomes after paste) looks like negative ?.
Note that the first ! remains unchanged, independent of whether if I
had to Option from the "Sekvan pagxon!" or "Antaùan pagxon!"; the
second ! gets replaced, the 3rd is preserved, the 4th is doubled.

  Klaus> In addition, strange things appear on the statusline (may
  Klaus> only be visible if Show Cursor is in effect).  (State B)

Yes, I see the letters ĭ� to appear to the right of the statusline.
Actually these are the non-ASCII characters from the anchors.  In the
Latin-1 version there appears the only non-ASCII letter of that
version, ù (from "Antaùan").


  >> up, leaving 3 blank underlined lines; the current anchor is
  >> duplicated, one in the old position below, filled and with the
  >> cursor at it, the other within the drifted text (as a passive
  >> link).  The active link can be followed; the other (shifted)
  >> anchors are dead.

  Klaus> Ok, this does sound familiar, although I cannot reproduce it
  Klaus> right now.  Especially the 3 or so blank lines looks
  Klaus> familiar.  When I have seen this, the effect was even worse
  Klaus> when viewing a local directory listing ('g .') or a
  Klaus> HTTP-server generated file listing IIRC, which became
  Klaus> completely unusable.

  Klaus> I think _this_ appears only with SLANG_MBCS_HACK and with
  Klaus> automatic margins on (plus some other conditions...).  For a
  Klaus> quick check, change the xterm's "Enable Auto Wraparound"
  Klaus> setting when this is happening (from xterm's Ctrl+mouse-2
  Klaus> menu).

I've set show_cursor off in the Options, Accepted the change, switched
off "Enable Auto Wraparound".  This did not improve the treatment of
the current page, but all the fresh pages (and the ex-current after
reload) became normal.

Well, almost normal.  At some links the status line accepts the COLOR
of the active link (there are at least two such links in
<>: one at
<>, another at

Maybe I should mention that presently I have


and the irregular statusline color is COLOR:6.


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

reply via email to

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