[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev dev.13 progress...
From: |
Hiroyuki Senshu |
Subject: |
Re: lynx-dev dev.13 progress... |
Date: |
Fri, 22 Oct 1999 10:09:16 +0900 |
It appreciates an immediate answer.
Well, details are shown in the following though
it is the problem which I pointed out.
Screen(OK)
---------------------
| English-texts
| ~~~~~~~~~~~~~
|
Screen(NG)
---------------------
| Japanese-texts
| ~~~~~~
|
'~~~~' means anchor's emphasis in this figure.
It is thinking about this problem by either one of
the next modification influencing it.
----
1999-10-21 (2.8.3dev.13)
:
* modified the way link text is (re-)drawn by function highlight. The bulk of
processing now happens in new function LYMoveToLink. The data of the
containing line is now scanned from the beginning, using the same logic as in
display_line to make sure that lynx and the display library have the same
idea of where in the line the link starts. In UTF-8 output mode, parts of
the line preceding the link are also repainted if this is necessary.
Refreshing of the physical line is forced if necessary in UTF-8 mode. For
anchors split across lines, the new approach is currently only used for the
first line.
This change is not in effect for lynx with color style. In that case
highlighting already is sometimes done in a similar similar, but not quite
the same, separate function.
* modified WHEREIS target highlighting for hypertext links. Now this is done
in the same pass as drawing the normal link text, in LYMoveToLink. This
avoids problems in UTF-8 display mode. It also avoids a lot of complicated
and extremely hard to understand older code in highlight(), but that code is
still there for use by lynx with color style and for other remaining cases
(non-hypertext anchors, second line highlighting).
* modified WHEREIS target highlighting for general text. Instead of first
writing each line's characters in display_line, then scanning again through
the line's data for portions to highlight and repainting those parts after in
display_page, this is now done in one pass within display_line. However,
this isn't (yet?) done for lynx with color style which still uses the old
code.
* these last three changes reduce problems that occur when using UTF-8 display
character set (in an appropriate terminal environment that understands it, of
course). Most of them don't apply with color style lynx, so it continues to
have more UTF-8 problems. Pages with mostly ASCII characters should be more
or less ok. Problems that otherwise are not visible become apparent in
search higlighting, and after ^Z / fg.
* GridText.c: More changes to deal with problems caused by using UTF-8 output
with a display library that isn't aware of it. Break line with UTF-8 before
curses does it. This causes lines that are too short, effectively the
rightmost part of a line cannot be used if there are UTF-8 encoded
characters. The alternative, letting curses wrap the line when it thinks it
got too long, is worse, so do it in lynx code instead.
* avoid memory overrun for very long lines in UTF-8 mode. Avoid splitting line
in the middle of a mutibyte UTF-8 character.
-----
Klaus Weide wrote:
>On Thu, 21 Oct 1999, Hiroyuki Senshu wrote:
>
>> Hello, lynx-dev.
>>
>> I tried dev.12c on Win32.
>
>> But, the emphasis indication of the anchor part isn't correct with dev.12c.
>> (Only a part becomes emphasis indication.)
>>
>> It seems to be the problem that it happens only
>> at the time as indication of Japanese.
>
>Please let us know, with concrete examples.
>
>But I cannot read Japanese and don't have any CJK fonts installed,
>so to make me understand you would have to describe the bad effect
>in much detail.
>
>I would also like to hear from any users of CJK display character
>sets for whom the new code *does* work right.
>
>It could be that there are some problems that only exist for one
>or more of
> #define CJK_EX .... CJK EXtension
> #define SH_EX .... Senshu Hiroyuki EXtension
> #define WIN_EX .... Windows EXtension
>
>
> Klaus
>
--Hiroyuki
P.S.
Add the following modification to the next edition.
diff -ur lynx283.d13/makefile.bcb lynx283.w32/makefile.bcb
--- lynx283.d13/makefile.bcb Fri Oct 22 08:09:18 1999
+++ lynx283.w32/makefile.bcb Thu Oct 21 17:03:14 1999
@@ -575,6 +575,11 @@
$(OBJ)/LYUpload.obj : src/LYUpload.c
$(BCC32) -P- -c @&&|
$(CEAT_lynxdexe) $(CC_FLAGS) -o$@ src/LYUpload.c
+|
+
+$(OBJ)/TRSTable.obj : src/TRSTable.c
+ $(BCC32) -P- -c @&&|
+ $(CEAT_lynxdexe) $(CC_FLAGS) -o$@ src/TRSTable.c
|
$(OBJ)/lyutils.obj : src/lyutils.c
--
Shonai College of Industry and Technology.
Electronics and Computer Information Course.
E-mail: address@hidden
- Re: lynx-dev TRST & centering (was: dev.13 progress...), (continued)
- Re: lynx-dev TRST & centering (was: dev.13 progress...), Klaus Weide, 1999/10/21
- Re: lynx-dev TRST & centering (was: dev.13 progress...), Kim DeVaughn, 1999/10/23
- lynx-dev restarting Lynx (was was), Philip Webb, 1999/10/23
- Re: lynx-dev restarting Lynx (was was), Kim DeVaughn, 1999/10/23
- Re: lynx-dev restarting Lynx, Michael Warner, 1999/10/23
- Re: lynx-dev restarting Lynx, Kim DeVaughn, 1999/10/24
- Message not available
- Re: lynx-dev TRST & centering (was: dev.13 progress...), Lloyd G. Rasmussen, 1999/10/21
Re: lynx-dev dev.13 progress..., Kim DeVaughn, 1999/10/20
Re: lynx-dev dev.13 progress..., Hiroyuki Senshu, 1999/10/21
Re: lynx-dev dev.13 progress..., T.E.Dickey, 1999/10/20
Re: lynx-dev dev.13 progress..., T.E.Dickey, 1999/10/20
Re: lynx-dev dev.13 progress..., Henry Nelson, 1999/10/22
Re: lynx-dev dev.13 progress..., Henry Nelson, 1999/10/22