Bug Hunting Session
Bug 33090 - Thai text in some UI elements will be displayed overlapped on Windows Vista / Windows 7
Summary: Thai text in some UI elements will be displayed overlapped on Windows Vista /...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 33891
  Show dependency treegraph
 
Reported: 2011-01-13 23:51 UTC by Tantai
Modified: 2012-12-22 01:21 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Input line (93.83 KB, image/png)
2011-01-13 23:52 UTC, Tantai
Details
Format code list box (150.19 KB, image/png)
2011-01-13 23:53 UTC, Tantai
Details
zero width mark (10.26 KB, image/png)
2011-02-14 02:09 UTC, Tantai
Details
with a zero width mark (10.25 KB, image/png)
2011-02-14 02:10 UTC, Tantai
Details
here's a ugly bug plausible temporary workaround (832 bytes, patch)
2011-04-01 09:03 UTC, Caolán McNamara
Details
proposed fix (1.46 KB, patch)
2011-04-01 12:56 UTC, Caolán McNamara
Details
screenshot of File > Properties > Description > Title box after typing "กินa" (11.66 KB, image/png)
2011-04-04 04:40 UTC, Samphan Raruenrom
Details
screenshot of Calc input box after typing "กินa" (13.90 KB, image/png)
2011-04-04 04:42 UTC, Samphan Raruenrom
Details
My Windows UI font setting (17.23 KB, image/png)
2011-04-04 21:07 UTC, Samphan Raruenrom
Details
this seems to work better (1.44 KB, patch)
2011-04-06 07:26 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tantai 2011-01-13 23:51:25 UTC
Step to reproduced :-

This will happen only when you enable  Tools > Options > Use system font for
user interface (which is the default).

1.Input line in Calc.
  1.1 Open OpenOffice.org Calc.
  1.2 Type “สวัสดี Hello ขอบคุณ Thanks” in the input line.
  1.3 You'll see the overlapped text in the input line.
2.List box.
  2.1 Open OpenOffice.org Calc.
  2.2 Choose menu Format > Cells.
  2.3 On the Numbers tab, choose Language: Thai, Category: Date.
  2.4 You'll see the overlapped text at the Format List box.
Comment 1 Tantai 2011-01-13 23:52:59 UTC
Created attachment 42002 [details]
Input line
Comment 2 Tantai 2011-01-13 23:53:45 UTC
Created attachment 42003 [details]
Format code list box
Comment 3 Caolán McNamara 2011-02-10 12:51:27 UTC
What does "tools->options->language settings->User interface" say btw, i.e. I'm trying to guess if the fonts from the "en" config or the "th" config are being used ?
Comment 4 Caolán McNamara 2011-02-10 12:58:33 UTC
And/or what *is* the system font, which should be under some windows preferences listing somewhere.
Comment 5 Tantai 2011-02-13 02:28:54 UTC
The language of user interface is "en" and the system font of windows by default is "Segoe UI"
Comment 6 Samphan Raruenrom 2011-02-14 01:56:16 UTC
Do you have any idea what's wrong?
We're looking at ImplLayoutRuns and SalLayout but there's no documentation or comment whatsoever so we're quite lost now.
Comment 7 Samphan Raruenrom 2011-02-14 02:08:20 UTC
Do you have any idea what's wrong?
We're looking at ImplLayoutRuns and SalLayout but there's no documentation or comment whatsoever so we're quite lost now.

I guess this is what's going on:-
1) LibO try to display mixed Thai/English string using Latin fonts like Seqoe UI
    Says the string is "ทดสอบ test"
2) It found that it need to fallback to, e.g. Tahoma, for the Thai part
3) It construct 2 runs in SalLayout? One for the Thai part. Second for the English part.
4) Things should be fine if the two runs are positioned correctly, which is the case for the above example. That is the 2nd runs is positioned immediately after the 1st run.  

But if we have one (or more) zero-width mark in the Thai part, the second runs will start right there at the mark. See the next screenshots.
Comment 8 Tantai 2011-02-14 02:09:27 UTC
Created attachment 43335 [details]
zero width mark

zero width mark
Comment 9 Tantai 2011-02-14 02:10:27 UTC
Created attachment 43336 [details]
with a zero width mark
Comment 10 Samphan Raruenrom 2011-02-14 02:13:44 UTC
The first screenshot is the test case "ทดสอบ test" which has no zero-width mark.
The second screenshot is the test case "ทดสับ test" which has one zero-width mark  ั between ส and บ
Comment 11 Samphan Raruenrom 2011-03-21 04:14:02 UTC
I've tried debugging the bug. Note: You must set the Option to “use system font for user interface” and the system font must not have Thai glyph (such as Segoe UI) so fallback mechanism kick-in.

Here's the steps I've tried.

1) First attach the debugger to the LO process, then 

2) In Writer, choose File > Properties > Description tab > Title box, type
กิน
(Using Thai keyboard, type “dbo”)

3) Then set the breakpoint at the (*pScriptTextOut)() call here
http://opengrok.libreoffice.org/xref/libs-gui/vcl/win/source/gdi/winlayout.cxx#2238 

4) Still in the Title box, type an English character “a” to make
กินa
The character “a” will be displayed *over* “น” which is the characteristic of this bug. The English text run will be displayed starting after the first non-spacing mark ( ิ )

5) The breakpoint will fire. LO is about to textout the Thai run “กิน”. Let's take note of some variables
aPos.nA = 0x9c --> X
aPos.nB = 0x39 --> Y
 (mpGlyphAdvances + nMinGlyphPos)[] = [7, 0, 7, 6] --> the width of each character in “กินa”

6) In the debugger, run to continue debugging. The breakpoint will fire again. LO is about to textout the English run “a”. Let's look at the variables again:-
aPos.nA = 0xa3  --> X
aPos.nB = 0x39  --> Y
 (mpGlyphAdvances + nMinGlyphPos)[] = [6] --> the width of the character “a”

Please note that the value of aPos.nA should be 0xaa (0x9c + 7 + 0 + 7) but it is 0xa3 (0x9c + 7). It seems like that computation of the width of the last text run is stop at the first non-spacing character. We can repeat the same process with different text and always reach the same conclusion. However, we can't find the code that compute the aPos.nA before textout each run.

Anyone has an idea where should I start looking?
Comment 12 Caolán McNamara 2011-04-01 06:57:11 UTC
We're in glyph fallback code here. 

The second Western Text fallback appears not to be getting set correctly, 

i.e. the derivation of nRunAdvance of


nXPos += nRunAdvance;

http://opengrok.libreoffice.org/xref/libs-gui/vcl/source/gdi/sallayout.cxx#1986
Comment 13 Caolán McNamara 2011-04-01 08:49:26 UTC
and the advance is wrong because the fallback ends early. 

Looks roughly like that in the non-windows case when we have multiple characters which get mapped to a single glyph we retain a record for the "missing" slot with an entry that maps it back to what character it came from. For the windows case we call uniscribes ScriptShape and don't have an entry for the "missing" slot, so we consider it the same as a truly missing glyph for the glyph fallback case.
Comment 14 Caolán McNamara 2011-04-01 09:03:53 UTC
Created attachment 45139 [details]
here's a ugly bug plausible temporary workaround
Comment 15 Caolán McNamara 2011-04-01 12:56:28 UTC
Created attachment 45149 [details]
proposed fix

This might be sufficient. If you could test this for me that'd be great.
Comment 16 Samphan Raruenrom 2011-04-01 21:27:37 UTC
Thanks Caolán :)

We will test the fix.
Comment 17 Samphan Raruenrom 2011-04-04 04:37:34 UTC
I've done some tests using the same test case "กินa" in
1) File > Properties > Description tab > Title box
2) Calc input box

The following are the result screenshots
Comment 18 Samphan Raruenrom 2011-04-04 04:40:54 UTC
Created attachment 45217 [details]
screenshot of File > Properties > Description > Title box after typing "กินa"

I've just finished typing "กินa" in the text box. The display is correct now. However, the cursor is placed incorrectly.
Comment 19 Samphan Raruenrom 2011-04-04 04:42:59 UTC
Created attachment 45219 [details]
screenshot of Calc input box after typing "กินa"

I've just finished typing "กินa" in Calc input box. Now both the display and the cursor position are correct!
Comment 20 Caolán McNamara 2011-04-04 07:08:43 UTC
I don't get the misplaced cursor in my file->properties box when I do
a) thai->thai kedmanee
dbo
b) en (US)
a

my cursor is correctly shown after the "a". When you do it, you get the cursor *before* the a, right ?
Comment 21 Samphan Raruenrom 2011-04-04 21:07:25 UTC
Created attachment 45249 [details]
My Windows UI font setting

To reproduce the bug, I have to use a UI font that miss Thai glyphs, such as "Segoe UI".
Comment 22 Samphan Raruenrom 2011-04-04 21:22:01 UTC
> my cursor is correctly shown after the "a". When you do it, you get the cursor
*before* the a, right ?

Yes. And if I continue typing latin characters, the cursor will stay at the position. If I type some Thai character, the cursor will advance. If then I type a latin character, the display will mixup again. See next attachment.
Comment 23 Samphan Raruenrom 2011-04-04 21:36:23 UTC
I find another bug. Here's how to reproduce
(See http://screencast.com/t/yGblVGEL0UQ )
1) in File > Properties > Descriptions > Title
2) type กิน (Using Thai keyboard, type “dbo”)
3) type a (the cursor will not move)
4) type กิน (the cursor will move, the text still displayed correctly)
5) type a (the character will be displayed over some previous character)
Comment 24 Caolán McNamara 2011-04-06 07:26:54 UTC
Created attachment 45344 [details]
this seems to work better

So, I can reproduce the overlapping with mixed runs, I don't see the cursor problem however (on master). Does the attached patch improve matters ?
Comment 25 Samphan Raruenrom 2011-04-12 04:26:29 UTC
Thanks. The new patch seems to fix the bug beautifully :) We'll test it more thoroughly anyway.

Regarding the cursor misplace problem, we don't see the problem on master build. On 3.3.2 release, we don't see the problem in Calc input line, but found it in File > Properties boxes.

The bug is currently like this:-
- when you type only Thai characters, both spacing and non-spacing, the cursor move accordingly
- when you type some Western characters, the cursor don't move a bit.
- you can continue to type Thai characters and the cursor will start to move again, as if the width of the Western characters don't count
Comment 26 Caolán McNamara 2011-04-15 06:12:44 UTC
oky doky, checked into master. Not pushed for 3.4 btw. Its a tricky area, so don't want to screw that until this has had some time to bed-down. Hopefully the other problem is orthogonal to this one.