GNU bug report logs - #5977
24.0.50; Lao HELLO is incorrectly displayed

Previous Next

Full log

Message #39 received at 5977-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 5977-done <at> debbugs.gnu.org
Subject: Re: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed
Date: Sun, 25 Apr 2010 17:40:47 +0300

> Cc: 5977-done <at> debbugs.gnu.org
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Sun, 25 Apr 2010 11:01:35 +0200
> 
> 
> Subtle changes of the "space" between (22, 11)/(22, 12) and (22, 33)/ 
> (22, 34) still exist when clicking on Braille characters. Also when  
> clicking into Telugu greeting in header.
> 
> Clicking into the Arabic or Hebrew (NATIVE NAME) comments moves the  
> coagulated greetings into the right column. Same when clicking into  
> their and the left parts (thirds) of Tibetan greetings or (9, 33)  
> Telugu example in the header.
> 
> When clicking into left half of Thai example in header the Hebrew line  
> is restored as left and right table cell.
> 
> clicking on (11, 44), Korean 하, merges Arabic and Bengali lines below  
> to one with roughly two columns, the right one far out.
> 
> "East Asia" line: Clicking on the Chinese BIG-5 example 早晨 makes  
> either Arabic line be correct with left and right cell or shifts the  
> greeting partly into the comment. The Chinese GB2312 example only  
> corrects Arabic and additionally adds a small bit of space into  
> Burmese comment and name, as described for clicking into Braille. The  
> SPACEs and COMMA near Chinese examples also change display of Arabic.
> 
> On "CJK variety" line each element of this copy "GB(元气,开发),  
> " (including the SPACE before the word BIG5) changes display of Arabic  
> (mostly establishes the two column view).
> 
> 
> Is this magic?

The changes on the Arabic and Hebrew lines are expected: there's
character composition there, and character compositions don't yet work
when text is reordered.  Depending on various redisplay optimizations
done on clicking, you can see all kinds of strange effects there, but
when you type "M-x redraw-display RET", you should again see those
lines in their initial (incorrect and unaligned) form.

The rest of the issues I don't understand.  I also don't see most of
them on MS-Windows, which is strange, since the code we are talking
about is implemented in the 100% device independent part of the
display engine.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.