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.
Created attachment 145271 [details] Demonstration of the bug
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.
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
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
(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.
(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
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
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.
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.
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!!!
*** Bug 121224 has been marked as a duplicate of this bug. ***
*** Bug 121251 has been marked as a duplicate of this bug. ***
*** Bug 121249 has been marked as a duplicate of this bug. ***