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.
Created attachment 42002 [details] Input line
Created attachment 42003 [details] Format code list box
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 ?
And/or what *is* the system font, which should be under some windows preferences listing somewhere.
The language of user interface is "en" and the system font of windows by default is "Segoe UI"
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.
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.
Created attachment 43335 [details] zero width mark zero width mark
Created attachment 43336 [details] with a zero width mark
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 บ
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?
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
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.
Created attachment 45139 [details] here's a ugly bug plausible temporary workaround
Created attachment 45149 [details] proposed fix This might be sufficient. If you could test this for me that'd be great.
Thanks Caolán :) We will test the fix.
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
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.
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!
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 ?
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".
> 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.
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)
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 ?
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
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.