Description: In the Windos64 version of LO Writer formulas with few inner scalable brackets have become broken. For instance, the following formula f <- left( func argmin csub {i in bold nitalic A} left( bold nitalic A left[ i right] right) right) has been rendered as it shown in https://pasteboard.co/Hzk04lN.png Steps to Reproduce: Just enter the formula from the description in the Writer's math editor Actual Results: In the formula incorrect shape of the brackets: https://pasteboard.co/Hzk04lN.png Expected Results: The formula with correct shape of all brackets. Reproducible: Always User Profile Reset: Yes Additional Info:
Created attachment 144207 [details] A screenshot with the brocken formula
Created attachment 144252 [details] Wrong render of scale brackets in Math
confirm in Версия: 6.1.0.3 (x64) ID сборки: efb621ed25068d70781dc026f7e9c5187a4decd1 Потоков ЦП: 4; ОС:Windows 10.0; Отрисовка ИП: по умолчанию; Локаль: ru-RU (ru_RU); Calc: CL
in 6.0.4.2 it doesn't confirm. regression
I got strange result after bibisecting: $ git bisect good 63fc3e0d41dd91f9fb3fe9891e009451285d9619 is the first bad commit commit 63fc3e0d41dd91f9fb3fe9891e009451285d9619 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Apr 26 01:55:57 2018 -0700 source 13a1bc409d9b2f0d14f4d316b7977b1fc2eb3c8a source 13a1bc409d9b2f0d14f4d316b7977b1fc2eb3c8a :040000 040000 6dff2bc547e94d95ef714c3cfbf47948b9f6b47b 62a9da32ed57c0b9cc357e308e775d828d29b570 M instdir but commit 13a1bc409d9b2f0d14f4d316b7977b1fc2eb3c8a was revert
I tried else one and if I see some small bug in render of brackets -> then I say good instead bad and I got another result hash. source bdccb7e9991d83029eb2f2f11327b54534a00db8
Windows only: not reproducible on Version: 6.1.1.0.0+ Build ID: 72fece73fbda7dc9fa34c4189cd9dfa10c9f2c51 Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; Ubuntu_18.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Calc: threaded and Version: 6.0.6.2 Build ID: 1:6.0.6-0ubuntu0.18.04.1 Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded Best regards. JBF
*** Bug 119339 has been marked as a duplicate of this bug. ***
(In reply to Roman Kuznetsov from comment #6) > I tried else one and if I see some small bug in render of brackets -> then I > say good instead bad and I got another result hash. > > source bdccb7e9991d83029eb2f2f11327b54534a00db8 This seems to be the correct result, as the revert to Noel's patch happened before this.
BTW the closed duplicate bug 119339 has a nice test document attached.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c177c305fc839e7a64d228ec56209d133588572b tdf#119302 WIN better font scale handling It will be available in 6.2.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.
these two commits as in 9a9b81c7212fa6a6762246593acf3f1950677a22 seem to complete the fix, stamping of the glyph into the calculated nodes are now accurate. https://gerrit.libreoffice.org/#/c/60092/ https://gerrit.libreoffice.org/#/c/60093/ while for the prior days be5e7fed5f8dc4ba95b890d8b364a8be97fa2739 build with just https://gerrit.libreoffice.org/#/c/60091/ the scalable bracket glyphs were not correctly positioned into their sm node. =-testing-= Windows 10 Pro 64-bit en-US with Version: 6.2.0.0.alpha0+ (x64) Build ID: 9a9b81c7212fa6a6762246593acf3f1950677a22 CPU threads: 8; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-07_23:40:38 Locale: en-US (en_US); Calc: threaded Version: 6.2.0.0.alpha0+ (x64) Build ID: be5e7fed5f8dc4ba95b890d8b364a8be97fa2739 CPU threads: 8; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-07_03:18:06 Locale: en-US (en_US); Calc: threaded
(In reply to V Stuart Foote from comment #12) > the scalable bracket glyphs were not correctly positioned into their sm node. what do you mean? for me scalable brackets shows fine now in Version: 6.2.0.0.alpha0+ Build ID: efe119aaa50e9f532b3fac1ef153469c80f24b80 CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-09-10_00:02:50 Locale: ru-RU (ru_RU); Calc: threaded
(In reply to Roman Kuznetsov from comment #13) > (In reply to V Stuart Foote from comment #12) > > > the scalable bracket glyphs were not correctly positioned into their sm node. > > > what do you mean? > Just that correct handling of the scalable brackets required all three commits. Agree this is now resolved in current master/6.2.0
Verified in Version: 6.2.0.0.alpha0+ Build ID: aaa3c31ba79b1b3d335dcf55d72837a13411b45e CPU threads: 16; OS: Windows 6.3; UI render: default; Locale: en-GB (en_GB); Calc: threaded @Jan-Marek Glogowski, should it be backported to 6.1 branch ?
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=974ad88c876cfabe0fb334b29cc04bb8a06fd5e9&h=libreoffice-6-1 tdf#119302 WIN better font scale handling It will be available in 6.1.3. 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.
Tested with today's LO 6.1.3dev All is fine ! Thank's for the work
*** Bug 120128 has been marked as a duplicate of this bug. ***
I tried LO 6.1.3.1, this bug is still present: https://pasteboard.co/HJ96uLa.png
(In reply to Serhii from comment #19) > I tried LO 6.1.3.1, this bug is still present: > https://pasteboard.co/HJ96uLa.png Could you please share the file you're using ?
Created attachment 145857 [details] Example of the broken formulas
In Win7, rendering is also broken: https://pasteboard.co/HJkAZ0R.png I attached the file with examples of broken formulas.
The sample document, attachment 145857 [details] does render correctly with master/6.2.0 builds--each formula must be selected to OLE open into Formula editor then "updated" <F9> final result clip attached. However, working with 6.1.3.1 build the same <F9> update of each formula cycles the scale, pushing formula onto new page. This is probably fixed for 6.1.4 as for bug 120204 and bug 119829: https://cgit.freedesktop.org/libreoffice/core/commit/?id=ac39aba9b2d08b061b0eef651f5ebc7a84391171&h=libreoffice-6-1
Created attachment 145859 [details] clip of attachment 148857 [details] opened and refreshed in current master/6.2.0 build
OK, so behavior is fixed for 6.1.4 builds Version: 6.1.4.0.0+ (x64) Build ID: 392ec204197c723b4dff4f7091df5afb46b5b9db CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-10-20_11:13:07 Locale: en-US (en_US); Calc: CL With both OpenGL rendering and default CPU, HA rendering.
*** Bug 120875 has been marked as a duplicate of this bug. ***
*** Bug 121712 has been marked as a duplicate of this bug. ***
*** Bug 121742 has been marked as a duplicate of this bug. ***