Apache OpenOffice (AOO) Bugzilla – Issue 61469
Thai: word completion cause cluster to be drawn twice
Last modified: 2013-08-07 14:44:35 UTC
Using Thai locale, some cases relating to word completion will cause a cluster in the word to be drawn twice. I can reproduce this only when the word is typed at the beginning of a document or a table cell. Step to reproduce :- 1. Switch to Thai locale. 2. Create a new Writer document. 3. Type "มิถ", Writer will suggest to complete the rest of the word which is " มิถุนายน" - the month June in Thai. Notice that the cluster "ถุ" is drawn twice. 4. Press enter to accept the word. The word still is displayed with double 'ถุ'. 5. You can save the document and reopen it, it'll be the same. 6. You can print the document and you'll see the same problem as on screen. Another case that you can try is (you need to blank the document first) :- 3. Type "พฤศ", Writer will suggest to complete the word as "พฤศจิà¸à¸²à¸¢à¸™" (November). 4. Don't accept the word. Type " ิ" (sara e), you'll get the cluster "ศิ" displayed twice.
Reassigned to SBA.
Created attachment 33757 [details] A test document with the problem at the beginning of the document and table cells
Created attachment 33758 [details] I've just found that the problem also occur everytime you switch paragraph style
Confirm on Windows XP. I can't reproduce it on my Ubuntu box.
SBA->samphan: Please always provide the keys one has to press when using a non-Thai keyboard (only having Thai input set). I do even have a Thai keyboard, too, but riddling about how to apply certain diacritics (and rebooting the machine for a new keyboard) is not exactly fun... SBA->FME: Please proceed.
FME: Type ,b5 on a German keyboard.
Since i21019, we set the language attribute according to the IME language during extended text input mode. In our example, the Thai language character attribute is assigned to the characters 3-7. Unfortunately characters 2 and 3 together form a character cluster but the text formatting separately processes two different character portions [0-2] and [3-7] due to the different attributes. I consider it quite hard to fix to handle attribute changes within a character cluster correctly. Therefore I suggest to check the language attribute at the input position during extended text input mode and skip the setting of the language attribute, if it is already set.
FME: Skipping the setting of the language attribute has a pro and a con: + small, local, low-risk fix - one the extended text input mode has been finished, the paint error does not occur anymore, however during the extended text input mode, we still have the paint error for the character cluster. Nevertheless, I think we should fix it this way. Any objections?
.
move to target 3.x according http://wiki.services.openoffice.org/wiki/Target_3x