lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev current_codepage in WIN_EX&&CJK_EX (was: Lynx .IDE file for Bor


From: Klaus Weide
Subject: lynx-dev current_codepage in WIN_EX&&CJK_EX (was: Lynx .IDE file for Borland C ++)
Date: Thu, 6 Jan 2000 01:43:17 -0600 (CST)

Some more comments, after thinking about it more:

On Wed, 5 Jan 2000, Hiroyuki Senshu wrote:
> Klaus Weide wrote:
> >On Sat, 8 Jan 2000, Vlad Harchev wrote:
> >
> >>  The 'current_codepage' is referenced in the following code fragement in
> >> LYCurses.c:
> >> 
> >> #if defined(WIN_EX) && defined(CJK_EX) /* 1999/08/26 (Thu) 17:53:38 */
> >>     {
> >>         extern int current_codepage;    /* PDCurses lib. */
> >> 
> >>         if (current_codepage == 932)
> >>             LYcols = COLS - 1;
> >>     }
> >> #endif
> >
> This code is necessary to indicate the character for which 
> to have width for two characters with one character
> with the English letter safely at the end of the line.
> [...]
> If it doesn't have this code, 
> the line of the blank is sometimes indicated, 
> and a discrepancy with the unit of a line to manage it inside occurs.

Lynx is designed to always avoid writing anything into the last cell
column (e.g., 80the column on a 80x25 screen; assumed below).  At
least for normal character data (-scrollbar is special stuff and is an
exception).

If character writing doesn't stop before the 80th column, (by
breaking/wrapping the line or truncating the displayed contents or
*something*,) then bad things may happen.  That's apparently what you
are running into in some CJK modus, and what you are trying to avoid.

It is HText_appendCharacter's responsibility to split lines early
enough (if lines are to be split).  It is display_line's
responsibility to not actually output something into the 80th column,
even if the line structure should be longer than displayable.  That
isn't always trivial.  Apparently one of those, or both, aren't doing
their job.  The problem should be fixed there, not by pretending that
the window is one cell narrower than it really is (that doesn't really
fix it, just works around it).

Utf-8 display mode also has similar kinds of problems that CJK modes
have, wrt. character counting.  They are solvable.

   Klaus



reply via email to

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