Bug 120204 - Scalable brackets: nodes with fractions and square roots are resized when updated <F9>
Summary: Scalable brackets: nodes with fractions and square roots are resized when upd...
Status: VERIFIED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
6.1.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.4
Keywords: bibisected, bisected, regression
: 121224 121249 121251 (view as bug list)
Depends on:
Blocks: Formula-Editor VCL-OpenGL CommonSalLayout-refactoring-regressions
  Show dependency treegraph
 
Reported: 2018-09-29 23:56 UTC by user234683
Modified: 2018-11-24 16:17 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstration of the bug (2.23 MB, video/x-flv)
2018-09-30 00:00 UTC, user234683
Details

Note You need to log in before you can comment on or make changes to this bug.
Description user234683 2018-09-29 23:56:56 UTC
Description:
When using scalable brackets (that is, left( <?> right) ) with fractions (that is {<?>}over{<?>}), the brackets will often be misaligned and too tall upon initial entry. The right bracket is always placed too high off center and is too tall at first. The left bracket is typically placed correctly and of the right height.

The issue seems to be stateful. That is, if the issue is fixed for a simple formula, the issue won't happen if that exact same formula is reentered. If a different type is entered, the issue will happen again.

The more complex the formula, the less likely it will be possible to perturb the formula in random ways to get it to render properly. Each perturbation will unpredictably change different combinations of scalable brackets. For simple formulas, pressing enter a few times is typically enough to resolve it.

This is all demonstrated in the video attachment.

Steps to Reproduce:
1. Open the formula editor, either directly or embedded in a writer document
2. Paste the following complicated formula: 
sqrt{
  left( {left({partial %rho}over{partial R} right)}over{%rho} %delta R right)^2
+ left( {left({partial %rho}over{partial d} right)}over{%rho} %delta d right)^2
+ left( {left({partial %rho}over{partial l} right)}over{%rho} %delta l right)^2
}


Actual Results:
The right brackets are extremely tall and are placed above center. The left brackets are more reasonable, but some of them are too big.

Expected Results:
The brackets should be aligned correctly and of the right size...


Reproducible: Sometimes


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Operating system: Windows 7 x64

Version: 6.1.1.2 (x64)
Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
CPU thread: 4; OS: Windows 6.1; UI render: default;
Locale: en-US(en_US); Calc: group threaded
(Unrelated suggestion: The about dialog should be selectable so this information can be copy and pasted)

The problem is not resolved by disabling OpenGL.
Comment 1 user234683 2018-09-30 00:00:10 UTC
Created attachment 145271 [details]
Demonstration of the bug
Comment 2 V Stuart Foote 2018-09-30 16:12:26 UTC
Confirming on Windows 10 Home 64-bit en-US (1803) with
Version: 6.2.0.0.alpha0+ (x64)
Build ID: ce9fd6d1329ecf4ab1f710472fbf55fd4bf0058d
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-21_23:53:25
Locale: en-US (en_US); Calc: threaded

But, believe there are two interrelated actions; 1.) recalculation of the nodes relative to other elements of the formula, 2.) then scaling/stamping the glyph into the element bounds for the node(s).

Recalculating--using the F9 or Update button--parses the entire formula. Believe nodes with "scalable" brackets, especially composite nodes including the OVER and SQRT notation, have a long present (StarOffice era) sequence flaw in calculating the node in relation to other composite nodes of the formula. That is very deep in the sm module.

Otherwise scaling/stamping the gylph into the node *is* affected by the rendering mode--OpenGL via DirectWrite has more trouble with the scaling/stamping compared to HA or CPU only Default rendering. The glyphs being scaled and stamped in Default rendering are less volatile.
Comment 3 Xisco Faulí 2018-10-17 15:36:52 UTC
So this is not happening in

Version: 5.4.0.0.alpha1+
Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
CPU threads: 16; OS: Windows 6.29; UI render: default; 
Locale: en-GB (en_GB); Calc: group

-> recent regression
Comment 4 Xisco Faulí 2018-10-18 15:28:03 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=bdccb7e9991d83029eb2f2f11327b54534a00db8

author	Jan-Marek Glogowski <glogow@fbihome.de>	2017-12-26 15:14:31 +0000
committer	Khaled Hosny <khaledhosny@eglug.org>	2018-05-08 00:55:27 +0200
commit	bdccb7e9991d83029eb2f2f11327b54534a00db8 (patch)
tree	c32e95c49849647dc72c1071f375f3d2b67d8d7a
parent	9615e45d2e2bac79c252a018846e4f20012cfa34 (diff)
Refactor CommonSalLayout font handling
Moves all platform specific code from CommonSalLayout into the
platform specific plugins. This way the vcl library won't depend
on the Qt5 libraries and the Qt5Font header can be moved into the
qt5 VCL plugin.

While at it, switch the CommonSalLayouts font reference from the
FontSelectPattern to the LogicalFontInstance and also add the
harfbuzz font handling to the instance.

Bisected with: bibisect-win32-6.1

Adding Cc: to Jan-Marek Glogowski
Comment 5 Jan-Marek Glogowski 2018-10-18 20:12:53 UTC
(In reply to V Stuart Foote from comment #2)
> Confirming on Windows 10 Home 64-bit en-US (1803) with
> Version: 6.2.0.0.alpha0+ (x64)
> Build ID: ce9fd6d1329ecf4ab1f710472fbf55fd4bf0058d
> CPU threads: 4; OS: Windows 10.0; UI render: GL; 
> TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-21_23:53:25
> Locale: en-US (en_US); Calc: threaded

I can't reproduce with master, but your build is a month old. My guess is it's the same bug then tdf#119829.

https://gerrit.libreoffice.org/61961 is untested, but much simpler then the solution implemented on master (a global shared LRU glyph cache). This just drops the cache for now as a simpler fix.

It looks like the same bug, because when you try to click the brackets, most bounding boxes are wrong.

Since I can't build 6.1, it's just a guess.
Comment 6 V Stuart Foote 2018-10-18 20:33:52 UTC
(In reply to Jan-Marek Glogowski from comment #5)
> (In reply to V Stuart Foote from comment #2)
> > Confirming on Windows 10 Home 64-bit en-US (1803) with
> > Version: 6.2.0.0.alpha0+ (x64)
> > Build ID: ce9fd6d1329ecf4ab1f710472fbf55fd4bf0058d
> > CPU threads: 4; OS: Windows 10.0; UI render: GL; 
> > TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-21_23:53:25
> > Locale: en-US (en_US); Calc: threaded
> 
> I can't reproduce with master, but your build is a month old. My guess is
> it's the same bug then tdf#119829.
> 
> https://gerrit.libreoffice.org/61961 is untested, but much simpler then the
> solution implemented on master (a global shared LRU glyph cache). This just
> drops the cache for now as a simpler fix.
> 
> It looks like the same bug, because when you try to click the brackets, most
> bounding boxes are wrong.
> 
> Since I can't build 6.1, it's just a guess.

Yes this is now WFM with current master, resolved between 2018-10-06 and 2018-10-08 builds as here, with several patches to of note:

https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=e7d5bad5ae083da12c3ec4a4a8bdc8b42447a242..e46f8a9a4e3c5b0542c0813b476b449f3af8d607
Comment 7 Xisco Faulí 2018-10-18 21:12:06 UTC
Indeed, no reproducible in

Version: 6.2.0.0.alpha0+
Build ID: 3f9c477929c261a8862411c00153e4c7d0d0ae7c
CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: en-GB (en_GB); Calc: threaded
Comment 8 Jan-Marek Glogowski 2018-10-18 21:45:41 UTC
So can someone test the Gerrit patch as a solution for 6.1? I don't have enough space left for a build to test.
Comment 9 Commit Notification 2018-10-19 06:14:17 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=ac39aba9b2d08b061b0eef651f5ebc7a84391171&h=libreoffice-6-1

tdf#120204 drop simple glyph cache

It will be available in 6.1.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.
Comment 10 Xisco Faulí 2018-10-19 12:49:00 UTC
Issue verified in

Version: 6.1.4.0.0+
Build ID: ac39aba9b2d08b061b0eef651f5ebc7a84391171
CPU threads: 16; OS: Windows 6.3; UI render: default; 
Locale: en-GB (en_GB); Calc: group threaded

@Jan-marek, thanks for the quick fix!!!
Comment 11 Xisco Faulí 2018-11-07 09:46:34 UTC
*** Bug 121224 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2018-11-07 15:03:44 UTC
*** Bug 121251 has been marked as a duplicate of this bug. ***
Comment 13 Xisco Faulí 2018-11-07 15:05:59 UTC
*** Bug 121249 has been marked as a duplicate of this bug. ***