Bug 119302 - Wrong rendering of math formulas with scalable brackets in Writer
Summary: Wrong rendering of math formulas with scalable brackets in Writer
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.2.0 target:6.1.4
Keywords: bibisected, bisected, regression
: 119339 120128 120875 121712 121742 (view as bug list)
Depends on:
Blocks: CommonSalLayout-refactoring-regressions
  Show dependency treegraph
 
Reported: 2018-08-15 18:30 UTC by Serhii
Modified: 2018-11-27 14:37 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
A screenshot with the brocken formula (80.23 KB, image/png)
2018-08-15 18:33 UTC, Serhii
Details
Wrong render of scale brackets in Math (6.05 KB, image/png)
2018-08-17 13:47 UTC, Roman Kuznetsov
Details
Example of the broken formulas (30.07 KB, application/vnd.oasis.opendocument.text)
2018-10-20 13:49 UTC, Serhii
Details
clip of attachment 148857 opened and refreshed in current master/6.2.0 build (83.35 KB, image/png)
2018-10-20 16:16 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Serhii 2018-08-15 18:30:29 UTC
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:
Comment 1 Serhii 2018-08-15 18:33:45 UTC
Created attachment 144207 [details]
A screenshot with the brocken formula
Comment 2 Roman Kuznetsov 2018-08-17 13:47:08 UTC
Created attachment 144252 [details]
Wrong render of scale brackets in Math
Comment 3 Roman Kuznetsov 2018-08-17 13:48:27 UTC
confirm in

Версия: 6.1.0.3 (x64)
ID сборки: efb621ed25068d70781dc026f7e9c5187a4decd1
Потоков ЦП: 4; ОС:Windows 10.0; Отрисовка ИП: по умолчанию; 
Локаль: ru-RU (ru_RU); Calc: CL
Comment 4 Roman Kuznetsov 2018-08-17 13:50:20 UTC
in 6.0.4.2 it doesn't confirm. 

regression
Comment 5 Roman Kuznetsov 2018-08-17 14:12:02 UTC
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 sha:13a1bc409d9b2f0d14f4d316b7977b1fc2eb3c8a

    source sha:13a1bc409d9b2f0d14f4d316b7977b1fc2eb3c8a

:040000 040000 6dff2bc547e94d95ef714c3cfbf47948b9f6b47b 62a9da32ed57c0b9cc357e308e775d828d29b570 M      instdir

but commit 13a1bc409d9b2f0d14f4d316b7977b1fc2eb3c8a was revert
Comment 6 Roman Kuznetsov 2018-08-17 14:50:59 UTC
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 sha:bdccb7e9991d83029eb2f2f11327b54534a00db8
Comment 7 Jean-Baptiste Faure 2018-08-18 07:47:08 UTC
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
Comment 8 Roman Kuznetsov 2018-08-18 08:07:38 UTC
*** Bug 119339 has been marked as a duplicate of this bug. ***
Comment 9 Aron Budea 2018-08-19 00:06:16 UTC
(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 sha:bdccb7e9991d83029eb2f2f11327b54534a00db8
This seems to be the correct result, as the revert to Noel's patch happened before this.
Comment 10 Jan-Marek Glogowski 2018-09-06 15:20:02 UTC
BTW the closed duplicate bug 119339 has a nice test document attached.
Comment 11 Commit Notification 2018-09-06 16:46:39 UTC
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.
Comment 12 V Stuart Foote 2018-09-08 03:32:57 UTC
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
Comment 13 Roman Kuznetsov 2018-09-13 08:44:12 UTC
(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
Comment 14 V Stuart Foote 2018-09-13 12:38:47 UTC
(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
Comment 15 Xisco Faulí 2018-09-18 15:26:29 UTC
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 ?
Comment 16 Commit Notification 2018-09-21 13:48:08 UTC
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.
Comment 17 Pierre C 2018-09-23 13:27:49 UTC
Tested with today's LO 6.1.3dev
All is fine ! Thank's for the work
Comment 18 V Stuart Foote 2018-09-26 12:39:27 UTC
*** Bug 120128 has been marked as a duplicate of this bug. ***
Comment 19 Serhii 2018-10-19 08:30:51 UTC
I tried LO 6.1.3.1, this bug is still present: https://pasteboard.co/HJ96uLa.png
Comment 20 Xisco Faulí 2018-10-19 09:33:59 UTC
(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 ?
Comment 21 Serhii 2018-10-20 13:49:40 UTC
Created attachment 145857 [details]
Example of the broken formulas
Comment 22 Serhii 2018-10-20 13:50:23 UTC
In Win7, rendering is also broken: https://pasteboard.co/HJkAZ0R.png
I attached the file with examples of broken formulas.
Comment 23 V Stuart Foote 2018-10-20 16:14:32 UTC
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
Comment 24 V Stuart Foote 2018-10-20 16:16:37 UTC
Created attachment 145859 [details]
clip of attachment 148857 [details] opened and refreshed in current master/6.2.0 build
Comment 25 V Stuart Foote 2018-10-20 17:40:56 UTC
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.
Comment 26 Xisco Faulí 2018-10-30 13:17:24 UTC
*** Bug 120875 has been marked as a duplicate of this bug. ***
Comment 27 Xisco Faulí 2018-11-26 12:40:28 UTC
*** Bug 121712 has been marked as a duplicate of this bug. ***
Comment 28 Xisco Faulí 2018-11-27 14:37:11 UTC
*** Bug 121742 has been marked as a duplicate of this bug. ***