Created attachment 120512 [details] Screenshot plus document triggering the bug To reproduce: - paste taste from the attached document - set font to Georgia - observe line breaks The problem disappears if font is changed to any other (for example, to Times New Roman or Liberation Serif). I found the bug by opening an ODT document created on the same machine using LibreOfficeWriter 4.2. I am sure text breaking was correct then. After opening in LibreOffice 5.0, the text was oddly broken in several paragraphs.
Bodhi 3.x LibreOffice 5.0.3 and 5.0.4 (developer release) Cannot confirm, file opens up looking fine
It opens fine in 4.3, bad in 5.0.3. Windows-only, not reproduced on Ubuntu (with Georgia installed). Win 7 Pro 64-bit, Version: 5.0.3.2 (x64) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: fi-FI (fi_FI) Version: 4.3.0.1 Build ID: 67f5430184326974072b65403ef1d9d934fc4481 Ubuntu 15.10 64-bit Version: 5.0.2.2 Build ID: 00m0(Build:2) Locale: en-US (en_US.UTF-8)
This seems to have begun at the below commit. Adding Cc: to Tor Lillqvist ; Could you possibly take a look at this one? Thanks 7f0371ad242095657660bb4862bcdfa4a28b4e2c is the first bad commit commit 7f0371ad242095657660bb4862bcdfa4a28b4e2c Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Aug 11 23:27:51 2015 -0700 source 4667db065d34193d99bce82f7e8f3b20a03ecade source 4667db065d34193d99bce82f7e8f3b20a03ecade author Tor Lillqvist <tml@collabora.com> 2015-08-12 05:18:50 (GMT) committer Tor Lillqvist <tml@collabora.com> 2015-08-12 06:14:20 (GMT) commit 4667db065d34193d99bce82f7e8f3b20a03ecade (patch) Drop SimpleWinLayout bibisect-win32-5.1 $ git bisect log # bad: [7af0dacdc70e7e8bd0785ab0be6e6ca64b64d08d] source 8bde421ccec9c10fe1382ad68485852889dd4c74 # good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65 git bisect start '7af0dacdc70e7e8bd0785ab0be6e6ca64b64d08d' 'c1efd324c6ad448ac9edb030dc9738b9e6899e4d' # good: [3f6a85ce123f4e0c065f1c28b02f66dc7734cc04] source 647b5aecd4c3facc302df33386451dda732aab98 git bisect good 3f6a85ce123f4e0c065f1c28b02f66dc7734cc04 # bad: [ef24bd27bb60c92140bf2f76403298d08f668abb] source f7dc03f666954b741b90c5021704249a4f76ed7b git bisect bad ef24bd27bb60c92140bf2f76403298d08f668abb # bad: [1074e6af309c093868bbf5caf9cf297a5b48d166] source df7fbad544679999c9635fc441571a0b52826d60 git bisect bad 1074e6af309c093868bbf5caf9cf297a5b48d166 # bad: [2a7daa76d03d68368b39c1709728c1e4fd6e01d8] source 79fb61efb847405fa47235002b52ee8efad5e339 git bisect bad 2a7daa76d03d68368b39c1709728c1e4fd6e01d8 # bad: [24e237f925572f95026b6b80a3f8a3f8b81455f5] source 7985e5245a57b284e370faccffcaab47ba137f3f git bisect bad 24e237f925572f95026b6b80a3f8a3f8b81455f5 # bad: [1a8003c2229ad845320d5dad411a91972ad5bd42] source 8aaee352aa39e624d2386d9b483855cd8069bff5 git bisect bad 1a8003c2229ad845320d5dad411a91972ad5bd42 # bad: [b3df4d951824fa01f9ef5ee4bce6a9a15c494666] source 2d4edd7de2e67db5bd17e7a89e2496611ebcc165 git bisect bad b3df4d951824fa01f9ef5ee4bce6a9a15c494666 # bad: [404b6fbf05583252758261abc7ef328ef283ea14] source 59b5e3faeb0564023e99f4e7298eb9cbb0bdc75f git bisect bad 404b6fbf05583252758261abc7ef328ef283ea14 # good: [b51adb834fc032eed77270683e8035d402f6932a] source f6595f0b3389ffeefa10035d915a884b02d26c0e git bisect good b51adb834fc032eed77270683e8035d402f6932a # bad: [c09504d6242d5c16aa8cc4bd0169788ef7b6d5d9] source 5975874141148e9f7199eca3a82735fccd7cf150 git bisect bad c09504d6242d5c16aa8cc4bd0169788ef7b6d5d9 # good: [4c1f4b142e3895f02567094986b0b57ad7df0e50] source 1e4b29e1ad16e908f550eae035c3fae8e56831dd git bisect good 4c1f4b142e3895f02567094986b0b57ad7df0e50 # bad: [7f0371ad242095657660bb4862bcdfa4a28b4e2c] source 4667db065d34193d99bce82f7e8f3b20a03ecade git bisect bad 7f0371ad242095657660bb4862bcdfa4a28b4e2c # good: [f8f8bdf24f7fc2f76810d36c4e1ce0e808c9509e] source 695cec87d73d56617e1cdc62621971ab35ac67eb git bisect good f8f8bdf24f7fc2f76810d36c4e1ce0e808c9509e # first bad commit: [7f0371ad242095657660bb4862bcdfa4a28b4e2c] source 4667db065d34193d99bce82f7e8f3b20a03ecade
The problem is caused by mishandling of glyph fallback in the UniscribeLayout code, it seems. It is the ΚΉ (U+02B9) character that causes the problem. (Just for information; of course LibreOffice should handle this fine and that it doesn't is a bug.)
Latest findings: The problem is caused by the (implicit, not tested by assertions) assumptions made in MultiSalLayout::GetTextBreak() not holding. The code seems to assume that the character widths calculated for the level 0 and the fallback levels don't overlap: that the level 0 char width is zero where a fallback level has a non-zero char width, and vice versa. But this is not the case for Windows, at least not any more now when using UniscribeLayout and not SimpleWinLayout. To be precise, the nWidth calculation in MultiSalLayout::GetTextBreak() accumulates way too fast, as characters have a width in both the level 0 and the fallback levels arrays, and thus the line is broken at around half of the width it actually could have. So now need to figure out why that is happening, and what the correct fix would be.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0d112a53023758a28d180ffd12766b4d325bf52 tdf#95783: Don't calculate width of text with glyph fallback as way too wide It will be available in 5.1.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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c08f837133226e85c9c4585b6135177b7c86d985&h=libreoffice-5-1 tdf#95783: Don't calculate width of text with glyph fallback as way too wide It will be available in 5.1.0.0.beta0. 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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b8711f6600216ca482627a928099a33612008734&h=libreoffice-5-0 tdf#95783: Don't calculate width of text with glyph fallback as way too wide It will be available in 5.0.4. 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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]