GNU bug report logs -
#5977
24.0.50; Lao HELLO is incorrectly displayed
Previous Next
Full log
Message #34 received at 5977-done <at> debbugs.gnu.org (full text, mbox):
Am 24.04.2010 um 12:36 schrieb Eli Zaretskii:
>>
>> The GNU Emacs 24.0.50 with this fix still has problems with HELLO
>> (Bzr-100013 in mode-line). The Lao greetings are different depending
>> on whether the text cursor (point) is outside or inside the text
>> strings:
>
> How did you place the cursor there? If by clicking the mouse, please
> see whether the problem disappears if you move cursor there by
> keyboard (C-f etc.).
I did by clicking with the mouse cursor. By text cursor movement no
changes appear.
When I later click into one of the Lao greeting words, then the shape
changes and changes back and it also happens that other characters can
"swallow" cursor key movements. For example, when I click on (44, 34)
than (44, 36) swallows events.
>
>> At the end of the visible characters the cursor jumps to a
>> completely unexpected position: early in the session it was the end
>> of
>> the Braille "Hello" (with column-number-mode enabled I still saw line
>> #44 and column #48) greeting, which later became visibly one line
>> above (line ending character of the Bengali greeting) while mode-line
>> still showed (44,48).
>
> AFAICS, <RIGHT> at the last character on a line positions cursor at
> the
> end of the first line displayed in the window. This is part of the
> cursor motion problems with composed characters. This part _is_
> visible on MS-Windows, and I'm working on it as we speak.
This effect is different in my X client. At the beginning of each line
I can type C-e followed by <RIGHT>, and the text cursor goes to the
next line below and is in column #0. This is what I expect. And I've
never seen (most probably) different behaviour, which I would classify
as a bug. From the Lao line C-e first leads to the end of the Braille
line, later to the end of the Bengali line. Next <RIGHT> leads to M of
Malayalam.
>> Clicking into the Braille "Hello" changes the Burmese greeting below
>> and the Burmese comment visibly... (normal first, clicked last)
>
> The two images you sent display identically on my system,
Yes, it's not easy to see, but it's there! And it does not happen
every time...
The differences are slightly more space in the comment string between
(22, 11) and (22, 12) and the greeting string between (22, 33) and
(22, 34).
> and I myself cannot try this because I don't have a Burmese font
> installed (are
> there good ones that are free?).
Yes, there are a few Unicode encoded. Besides UniBurma I have Sun-
ExtA, Padauk (bold and regular), and of course Code2000! For me GNU
Emacs chose
xft:-unknown-UniBurma-normal-normal-normal-*-13-*-*-*-*-0-
iso10646-1 (#x16)
which is both a TT and OT font installed (as the latter) in Mac OS X
and provided to X11 via X server (mkfontscale/mkfontdir, xlsfonts) and
libfontconfig.
Do you know the "Gallery of Unicode Fonts" at http://www.wazu.jp/? The
"Unicode Font Guide For Free/Libre Open Source Operating Systems" at http://www.unifont.org/fontguide/
might offers some resources.
Later I'll have the NS (Mac OS X/Cocoa/Aqua client) variant compiled
to see how HELLO there works... And maybe also time to report (most
likely not).
>
>> Should I bug-report new Thai, Burmese, and Arabic/Hebrew HELLO bugs?
>
> The bugs are not new. You can file the bugs, but if you do, please
> file 3 separate reports:
>
> . character composition doesn't work with bidi-reordered text
> . mouse clicking HELLO changes some characters
> . cursor motion incorrect at end of line that ends in a composite
> character
When they're already known then I'll keep silent.
--
Greetings
Pete
If we don't succeed, we run the risk of failure.
– George W. Bush
This bug report was last modified 15 years and 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.