Created attachment 47742 [details] Sample of bugs 1. Type any Thai characters. 2. Insert the → character 3. LibreOffice rearrange the position of Thai characters. 4. Type any characters. These characters will appear incorrectly on this line.
RC2 is bit by bit identical with release version, so separate items in the version picker are useless. Changes have been discussed with Michael Meeks.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Reproduced in 3.6.1 on Fedora 64 bit Steps to reproduce: 0. Open attachment 1. Select arrow in text and press Ctrl-C 2. Place text cursor inside of Thai word and press Ctrl-V Expected: arrow inserted and distance between lines of text will not change Actually: arrow inserted and distance between lines *decreases* and this changing of distance is not undoable. Not reproduced in 3.3.4, therefore Regression
On pc Debian x86-64 with 3.6 sources updated today, I don't reproduce the problem (I followed comment7's Sasha). Perhaps I missed something. Could anybody give a try to 3.6.2 (or prerelease 3.6.3)?
reproduced in 3.5.7 (from Fedora repo) and 3.6.2 (rpm from libreoffice.org) on RFR 17 64 bit but not reproduced in 3.6.2 on Windows XP 32 bit
so... the problem that i can see here is that after loading the attached document, any change to a line that includes Thai characters causes the inter-line spacing above the line to shrink. the Undo does not restore the document view to how it looked before. it's not even necessary to edit the text; changing the zoom level also causes the gaps to shrink (all at once). this is happening here in any LO/OOo release from OOo 3.3 onwards, did not happen in OOo 3.2.1. so i'm guessing that the layout after the file is imported is not complete (i.e. document is displayed wrongly right after import) and any tweak causes it to reach a more stable state.
so the mysterious VCL font cache will return a font with maSearchName = "waree" and mnLineHeight 3592 for this one: p *rFont.mpImplFont $2 = { mnRefCount = 5, maFamilyName = "TH SarabunPSK", maStyleName = "", maSize = Size = { width = 0, height = 360 }, maColor = rgba(255, 255, 255, 255), maFillColor = rgba(255, 255, 255, 255), meCharSet = 76, meLanguage = 1054, meCJKLanguage = 2052, meFamily = FAMILY_SWISS, mePitch = PITCH_VARIABLE, meAlign = ALIGN_BASELINE, meWeight = WEIGHT_NORMAL, meWidthType = WIDTH_DONTKNOW, meItalic = ITALIC_NONE, meUnderline = UNDERLINE_NONE, meOverline = UNDERLINE_NONE, meStrikeout = STRIKEOUT_NONE, meRelief = RELIEF_NONE, meEmphasisMark = 0, mnOrientation = 0, mnKerning = 1 '\001', mbWordLine = 0 '\000', mbOutline = 0 '\000', mbConfigLookup = 0 '\000', mbShadow = 0 '\000', mbVertical = 0 '\000', mbTransparent = 1 '\001' } but with the following parameter it returns maSearchName = "dejavusans" and mnLineHeight 2514: p *rFont.mpImplFont $5 = { mnRefCount = 5, maFamilyName = "TH SarabunPSK", maStyleName = "", maSize = Size = { width = 0, height = 360 }, maColor = rgba(255, 255, 255, 255), maFillColor = rgba(255, 255, 255, 255), meCharSet = 76, meLanguage = 1033, meCJKLanguage = 2052, meFamily = FAMILY_SWISS, mePitch = PITCH_VARIABLE, meAlign = ALIGN_BASELINE, meWeight = WEIGHT_NORMAL, meWidthType = WIDTH_DONTKNOW, meItalic = ITALIC_NONE, meUnderline = UNDERLINE_NONE, meOverline = UNDERLINE_NONE, meStrikeout = STRIKEOUT_NONE, meRelief = RELIEF_NONE, meEmphasisMark = 0, mnOrientation = 0, mnKerning = 1 '\001', mbWordLine = 0 '\000', mbOutline = 0 '\000', mbConfigLookup = 0 '\000', mbShadow = 0 '\000', mbVertical = 0 '\000', mbTransparent = 1 '\001' } ... where the only difference appears to be meLanguage? the different mnLineHeight ultimately causes the different formatting...
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb51791ae49ecded0f618b4534893adb8fcf917e fdo#38090: vcl: remove ImplFontCache::maFontNameList: The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=835cae7e323b9831d11f5f4957933728f561e71a&g=libreoffice-4-0 fdo#38090: vcl: remove ImplFontCache::maFontNameList: It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
since Caolan's on vacation i'll just call it FIXED...
Thanks for fixing this bug