lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev CJK partial highliting of link in dev.13


From: Klaus Weide
Subject: lynx-dev CJK partial highliting of link in dev.13
Date: Fri, 22 Oct 1999 06:19:05 -0500 (CDT)

On Fri, 22 Oct 1999, Hiroyuki Senshu wrote:

> Henry Nelson wrote:
> >Please explain what I should be looking for.  For example, if I move
> >the cursor over the link:
> ><a href="http://www.yahoo.co.jp/";>$B!V%d%U!<!W(B</a>
> >                                  ||||~~~~~~
> >maybe only the first two characters are in bold (||||), and the others
> >are not (~~~~~~), i.e., just like plain text?
> 
> Yes!
> 
> But, the part of (~~~~~) is indicated under the condition
> which emphasis isn't put on as a usual character.
> 
> It appreciates having it changed to the proper expression.

Ok, I see it now...
Yes, I screwed up the highlighting for CJK, sorry.

I think I understand what is wrong.  I had a misunderstanding
about what the function LYmbcsstrlen() does in the CJK case.
(That function is in LYStrings.c.)
Actually, what it does seems wrong...  it should return the number
of character cells, counting kanji as 2 not 1.

Problem is cause by using the wrongly-behaving function at beginning of
move_to_glyph() in GridText.c:
    linkvlen = hightext ? LYmbcsstrlen(...

The older code in highlight() (which the new code in part makes
unnecessary) *also* seems to assume that LYmbcsstrlen() acts that
way when it never did.   That means that parts of hightlight() have
been wrong for CJK for a long time: Highlighting of WHEREIS ('/')
target string that falls in anchor text - it is positioned right at
first (before link is made current link), but when making the link
current (and thereafter) the wrong character(s) will be highlighted.
The wrongfully highlit characters will be left of the rightful owners
of the highlight, and highlighting may happen in the middle of double
byte characters (thus breaking them?).

To see the effect, the anchor text should have CJK characters before
the occurrence of the target string.  Can someone confirm the
existence of this old problem with CJK display character sets?
*That* problem is gone with the new code.

Anyway, the correction for the new (and the old and less obvious)
problem would be to fix LYmbcsstrlen.  It isn't called anywhere else,
and the 2 or 3 places where it is called expect the cell-couunting
behavior.

Please test the following "patch":

In LYStrings.c at the end of function 'PUBLIC int LYmbcsstrlen',
remove the following four lines:

        } else if (!utf_flag && HTCJK != NOCJK && !isascii(str[i]) &&
                    str[(i + 1)] != '\0' &&
                    !IsSpecialAttrChar(str[(i + 1)])) {
            i++;



(I admit I haven't tested it at all yet.  It *should* be right...)

   Klasu



reply via email to

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