Bug Hunting Session
Bug 99351 - Square root of fraction doesn't display correctly -- sqrt when an over expression is part of a node (comment 21)
Summary: Square root of fraction doesn't display correctly -- sqrt when an over expres...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
5.1.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: high major
Assignee: Michael Meeks
URL:
Whiteboard: target:5.4.0 target:5.3.2
Keywords:
: 100190 100645 101031 101883 102254 104092 104208 106930 108502 (view as bug list)
Depends on: hb_ot_math
Blocks: Formula-Editor VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-04-16 19:17 UTC by ondrej.schifauer
Modified: 2017-06-13 17:12 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of formula (87.52 KB, image/png)
2016-04-16 19:17 UTC, ondrej.schifauer
Details
OpenGL log (313 bytes, text/plain)
2016-04-17 18:24 UTC, ondrej.schifauer
Details
comparing rendeing of example formulas with and without OpenGL (181.10 KB, application/vnd.oasis.opendocument.graphics)
2016-05-16 21:14 UTC, V Stuart Foote
Details
sqrt and over nodes for formula with OpenGL (53.16 KB, image/png)
2016-06-27 20:25 UTC, V Stuart Foote
Details
sqrt and over nodes for formula with out OpenGL rendering enabled (45.70 KB, image/png)
2016-06-27 20:41 UTC, V Stuart Foote
Details
sample formula with new Harfbuzz based shaping and default rendering (45.34 KB, image/png)
2016-10-21 18:44 UTC, V Stuart Foote
Details
sample formula with new Harfbuzz based shaping and OGL rendering (21.09 KB, image/png)
2016-10-21 19:12 UTC, Roman Kuznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ondrej.schifauer 2016-04-16 19:17:02 UTC
Created attachment 124412 [details]
Screenshot of formula

Enter formula: sqrt{ {a} over {b} }
It will be displayed incorrectly.

Used fonts: Liberation Serif
Version: 5.1.2.2
Windows 7 (64 bit)
Comment 1 raal 2016-04-17 15:37:41 UTC
I can not confirm with  5.1.2.2 (x64), win7

Have you tested the options for the graphics card in Menu/Tools/LibreOffice/View?
Disabling the OpenGL
Comment 2 ondrej.schifauer 2016-04-17 15:55:32 UTC
I didn't think of that.
Yes, it was because of the OpenGL.

I guess that OpenGL implementation needs some improvements.
I think that OpenGL shouldn't be enabled by default if it has this kinds of error.

Does this count as resolved? Because the bug is still there if OpenGL is enabled.
Comment 3 raal 2016-04-17 18:12:48 UTC
Please take a look at
C:\Users\User_name\AppData\Roaming\LibreOffice\4\cache\opengl_device.log

Do you have this file on your PC? If yes, please attach it

Also some improvements was coded in dev version, so testing is appreciate. Dev version you can download here: http://dev-builds.libreoffice.org/daily/master/
Thank you
Comment 4 ondrej.schifauer 2016-04-17 18:24:53 UTC
Created attachment 124438 [details]
OpenGL log

Here is that log.
Comment 5 V Stuart Foote 2016-04-17 19:46:40 UTC
Not just Windows 7, also 8.1 and 10

With OpenGL rendering enabled the scaling and positioning of the U+221A "Square Root" radical glyph is off.  

Without OpenGL the scaling of the glyph is close, but with 8.1 and 10 unexpected font substitution occurs and we get Segoe UI rather than OpenSymbol so metrics don't quite match--and the  tip of the radical does not meet the horizontal line constructed above the radican.
Comment 6 Tor Lillqvist 2016-05-11 11:43:48 UTC
Please give more detailed reproduction instructions. Developers are not necessarily used to actually using LibreOffice, and just saying "Enter formula: sqrt{ {a} over {b} }" is far from enough for me to understand what to do, for instance.
Comment 7 raal 2016-05-11 12:34:56 UTC
(In reply to Tor Lillqvist from comment #6)
> Please give more detailed reproduction instructions. Developers are not
> necessarily used to actually using LibreOffice, and just saying "Enter
> formula: sqrt{ {a} over {b} }" is far from enough for me to understand what
> to do, for instance.

Open new writer
menu Insert - object - Formula
write or paste: sqrt{ {a} over {b} }
click to the document
Comment 8 V Stuart Foote 2016-05-11 13:12:22 UTC
(In reply to raal from comment #7)
> 
> Open new writer
> menu Insert - object - Formula
> write or paste: sqrt{ {a} over {b} }
> click to the document

Or work directly in a new Math Formula, as this is an issue against the math formula editor.

Pane on the left is the Elements Dock
Pane on the bottom is the Formula editor
Remaining large pane is the Preview Window

Formulas are entered as StarMath markup typed or pasted into the Formula editor.

So, to reproduce glyph issue paste the given StarMath markup "sqrt{ {a} over {b} }" into the Formula editor pane, result will show in the Preview Window.

Fonts and Symbol assignments can be modified from defaults using dialogs reached from the main menu:

Format -> Fonts
Tools -> Symbols

=-ref-=
https://wiki.documentfoundation.org/images/2/26/MG44-MathGuide.pdf
Comment 9 Tor Lillqvist 2016-05-12 08:11:23 UTC
OK, thanks. Yes, I see it in a fresh 5.1 build.
Comment 10 Tor Lillqvist 2016-05-12 08:16:52 UTC Comment hidden (obsolete)
Comment 11 Tor Lillqvist 2016-05-12 08:25:33 UTC Comment hidden (obsolete)
Comment 12 Tor Lillqvist 2016-05-12 09:14:42 UTC
(of developer interest only:) Setting SAL_DISABLE_GLYPH_CACHING improves the layout of the square root sign, at least it is not on top of the other glyphs any more. But the horizontal bar is not attached correctly to the initial V-like part of the sign. So an initial workaround for the bug would be to make sure we don't even attempt to cache glyphs of mathematical symbols... or somesuch hack.
Comment 13 Tor Lillqvist 2016-05-12 10:00:02 UTC
But it isn't straightforward to figure out how to notice that a font is one used for mathematical symbols. For instance the IsSymbolFont() is not what one could use; OpenSymbol (which is the font that gets used for the square root sign for me at least) is *not* a "symbol" font from that perspective.

I quote caolan: '"symbol" fonts are fonts that stick random symbols into random locations, e.g. wingdings. write "apple" change the font to wingdings and you get a string of random symbols. "opensymbol" is a font with glyphs correct identified as what they actually are in unicode plus some random symbols put into the private use area'
Comment 14 Tor Lillqvist 2016-05-13 11:29:58 UTC
I now notice that some recent change to the 5.1 branch has fixed this... and in master, too. Resolving as WORKSFORME.
Comment 15 Tor Lillqvist 2016-05-13 12:00:10 UTC
The "the horizontal bar is not attached correctly to the initial V-like part of the sign" thing is apparently nothing new, it has been like that all the time? Oh well.
Comment 16 V Stuart Foote 2016-05-16 21:14:44 UTC
Created attachment 125105 [details]
comparing rendeing of example formulas with and without OpenGL

@Tor, *

Reopening as we still have composition issues with Math formulas. It is More than just closing the square root glyph. In the Math Formula editor, drop list menu for the left hand pane there is an Examples category.

Have a look at the last two examples which have the following StarMath notation:

f ( x ) = sum from { { i = 0 } } to { infinity } { {f^{(i)}(0)} over {i!} x^i}

and

f ( x ) = {1} over {%sigma sqrt{2%pi} }func e^-{{(x-%mu)^2} over {2%sigma^2}}

respectively.

With OpenGL rendering enabled the sqrt glyph handling is just one facet, it is being "closed" with its bar now, unfortunately the length of the minus signs are being stretched--that is just annoying really.

Bigger issue is with composing the sum statements, both with and without OpenGL. They've really gone crazy with latest glyph handling, both OpenGL and default rendering.

Posting clips as a Draw document.
Comment 17 Tor Lillqvist 2016-05-24 13:19:33 UTC
Stuart, if you now re-opened the bug to no longer be specific to OpenGL behaviour, I will then remove 93529 from the list of blocked bugs, OK?
Comment 18 V Stuart Foote 2016-05-24 16:24:08 UTC
Just checked on Windows 10 Pro 64-bit en-US with
Version: 5.2.0.0.alpha1+ (x64)
Build ID: fa9416906e615f5f19ad8524176d2ed693662769
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-05-24_00:06:07
Locale: en-US (en_US)

and with 

Version: 5.2.0.0.alpha1+
Build ID: 7b704dfbdb23540ff6366fa60c73474bbda9dc26
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-05-20_05:45:40
Locale: en-US (en_US)

The square root glyph does not close with its bar without OpenGL rendering, but the more extreme issues I'd been seeing with symbol composition in Math formulas (picked from the StarMath examples list)  both with and without OpenGL rendering have resolved.

Resolving WFM
Comment 19 V Stuart Foote 2016-06-02 16:12:44 UTC
*** Bug 100190 has been marked as a duplicate of this bug. ***
Comment 20 V Stuart Foote 2016-06-02 16:33:23 UTC
@Tor, Michael, *

(In reply to V Stuart Foote from comment #19)
> *** Bug 100190 has been marked as a duplicate of this bug. ***

Sorry to reopen but not sure this is fully quashed on master. Entering the StarMath formula from dupe bug 100190:

sqrt { 2 m over 2 }

with OpenGL rendering enabled, the glyph for the Square Root radical is again shifting into the formula.

or, the OPs sample formula:

sqrt{ {a} over {b} }

On Windows 10 Pro 64-bit en-US with a new default profile
Version: 5.3.0.0.alpha0+
Build ID: cbf36dd473fdc9e8d8b78c9e9317836a7cbbc6c7
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-06-01_00:32:07
Locale: en-US (en_US)

When OpenGL rendering is enabled, the issue occurs. With out OpenGL rendering, the formula is close to correct (the glyph does not stretch to meed the bar).

This seems to be a specific issue with logic of placing the Square Root radical, more complex Star Math formulas of comment 16 are rendered correctly.
Comment 21 V Stuart Foote 2016-06-03 17:44:53 UTC
(In reply to V Stuart Foote from comment #20)

The OpenGL DirectWrite composition issue seems to be only with the "SQRT" or "NROOT" function, when the "OVER" function is applied to the body of the node.

When the "OVER" function is not part of the node, the root formula is being correctly composed.

Without OpenGL rendering enabled, the root formula node that includes an "OVER" function is composed correctly.

I looked for a while but could not figure out the linkage between the SQRT or NROOT when the OVER function is a subnode of the formula node.


=-refs-=
http://opengrok.libreoffice.org/xref/core/starmath/source/node.cxx#745
http://opengrok.libreoffice.org/xref/core/starmath/inc/node.hxx#756 //root
http://opengrok.libreoffice.org/xref/core/starmath/inc/node.hxx#374 //OVER
http://opengrok.libreoffice.org/xref/core/starmath/inc/node.hxx#1250 //composing
Comment 22 V Stuart Foote 2016-06-27 20:15:48 UTC
*** Bug 100645 has been marked as a duplicate of this bug. ***
Comment 23 V Stuart Foote 2016-06-27 20:25:53 UTC
Created attachment 125950 [details]
sqrt and over nodes for formula with OpenGL
Comment 24 V Stuart Foote 2016-06-27 20:41:09 UTC
Created attachment 125951 [details]
sqrt and over nodes for formula with out OpenGL rendering enabled

Two attached formulas compare corruption when OpenGL is enabled of formula containing a SQRT when a node contains an OVER element.

Notice that in addition to the mis-attachment of the SQRT to its bar, that it and the Parenthesis glyphs are also scaled and positioned oddly with OpenGL rendering.

This is on Windows 8.1 Ent 64-bit en-US with default profile.
Comment 25 V Stuart Foote 2016-07-20 18:19:23 UTC
*** Bug 101031 has been marked as a duplicate of this bug. ***
Comment 26 V Stuart Foote 2016-09-03 21:14:28 UTC
*** Bug 101883 has been marked as a duplicate of this bug. ***
Comment 27 V Stuart Foote 2016-10-06 16:22:36 UTC
*** Bug 102254 has been marked as a duplicate of this bug. ***
Comment 28 Buovjaga 2016-10-21 18:27:38 UTC
Correcting status to NEW, as no commits.
Comment 29 V Stuart Foote 2016-10-21 18:44:32 UTC
Created attachment 128138 [details]
sample formula with new Harfbuzz based shaping  and default rendering

Work on the new Harfbuzz based SAL common layout does some good here.

test formula:

X_{ 1,2 } = 5+sqrt{  left( 4 over 2 right)^2 - 1 }

Need to see it whith OpenGL rendering.
Comment 30 Roman Kuznetsov 2016-10-21 19:12:59 UTC
Created attachment 128139 [details]
sample formula with new Harfbuzz based shaping and OGL rendering

Версия: 5.2.3.1
ID сборки: 01ec8f357e651ca9656837b783cf7e6a32ee4d92
Потоков ЦП: 4; Версия ОС: Windows 6.1; Отрисовка ИП: GL; 
Локаль: ru-RU (ru_RU); Calc: group

video AMD 6650, OGL - Enabled
Comment 31 V Stuart Foote 2016-10-21 19:21:10 UTC
(In reply to kompilainenn from comment #30)
> Версия: 5.2.3.1

Harfbuzz based rendering required current (after 2016-10-17) master or 5.3.0 Alpha1 and must be enabled.  Through today's builds OpenGL rendering is all in the alpha channel so unreadable--bug 103365, tomorrows build should be patched and let us get a look.
Comment 32 Roman Kuznetsov 2016-10-21 20:37:00 UTC
(In reply to V Stuart Foote from comment #31)
> (In reply to kompilainenn from comment #30)
> > Версия: 5.2.3.1
> 
> Harfbuzz based rendering required current (after 2016-10-17) master or 5.3.0
> Alpha1 and must be enabled.  Through today's builds OpenGL rendering is all
> in the alpha channel so unreadable--bug 103365, tomorrows build should be
> patched and let us get a look.

in 

Версия: 5.3.0.0.alpha1
ID сборки: f4ca1573fcf445164c068c1046ab5d084e1b005f
Потоков ЦП: 4; Версия ОС: Windows 6.1; Отрисовка ИП: GL; 
Локаль: ru-RU (ru_RU); Calc: group

view of formula, as on my last screenshot (horrible).
Comment 33 V Stuart Foote 2016-10-22 00:16:00 UTC
(In reply to kompilainenn from comment #32)
> 
> in 
> 
> Версия: 5.3.0.0.alpha1
> ID сборки: f4ca1573fcf445164c068c1046ab5d084e1b005f
> Потоков ЦП: 4; Версия ОС: Windows 6.1; Отрисовка ИП: GL; 
> Локаль: ru-RU (ru_RU); Calc: group
> 
> view of formula, as on my last screenshot (horrible).

Did you enable the Harfbuzz common shaping with "SET SAL_USE_COMMON_LAYOUT=1" and then launch. Otherwise you are still seeing D2Write with OpenGL and nothing would have changed.
Comment 34 Roman Kuznetsov 2016-10-22 16:04:55 UTC
(In reply to V Stuart Foote from comment #33)

 
> Did you enable the Harfbuzz common shaping with "SET
> SAL_USE_COMMON_LAYOUT=1"

How to make this?
Comment 35 zac.renaud 2016-10-22 16:18:57 UTC
(In reply to V Stuart Foote from comment #33)
> (In reply to kompilainenn from comment #32)
> > 
> > in 
> > 
> > Версия: 5.3.0.0.alpha1
> > ID сборки: f4ca1573fcf445164c068c1046ab5d084e1b005f
> > Потоков ЦП: 4; Версия ОС: Windows 6.1; Отрисовка ИП: GL; 
> > Локаль: ru-RU (ru_RU); Calc: group
> > 
> > view of formula, as on my last screenshot (horrible).
> 
> Did you enable the Harfbuzz common shaping with "SET
> SAL_USE_COMMON_LAYOUT=1" and then launch. Otherwise you are still seeing
> D2Write with OpenGL and nothing would have changed.
Hi 
I try Harfbuzz on my Windows 10 pc. The system stop the program installation.

I have discorver that only the screen windows is wrong on printing no problem
All formulas are correct
Comment 36 V Stuart Foote 2016-10-22 16:59:12 UTC
(In reply to kompilainenn from comment #34)
> (In reply to V Stuart Foote from comment #33)
> 
>  
> > Did you enable the Harfbuzz common shaping with "SET
> > SAL_USE_COMMON_LAYOUT=1"
> 
> How to make this?

Perform normal "msiexec.exe /a" administrative installation of the MSI, and complete that configuration (see installing in parallel in the Wiki).

Open a command window (cmd.exe) and navigate to the <install location>\program folder.

In the command window, issue the command: "set SAL_USE_COMMON_LAYOUT=1"
that sets the environment variable (check it is listed by issuing "env")

In the command window, launch LibreOffice with command: ".\soffice.exe"

When the instance of LibreOffice launches it will have enabled the new HarfBuzz based common layout. Additional open and closing of LibreOffice from that command window will continue to use HarfBuzz shaping. When done, simply close LibreOffice and close the command Window and it all reverts to the normal D2Write/Dwrite based rendering. 

For now, it is not persistent, so to re-enable you have to work from a command window with the env variable set.
Comment 37 Mike Kaganski 2016-11-05 05:57:21 UTC
(In reply to V Stuart Foote from comment #36)
> For now, it is not persistent, so to re-enable you have to work from a
> command window with the env variable set.

In current master, HarfBuzz is enabled by default; but just FYI: if required, you may set environment variable to be persistent using SystempPopertiesAdvanced.exe (Environment Variables button). Depending on whether you set it per-user or per-machine, you will need either relogon or reboot.
Comment 38 Mike Kaganski 2016-11-05 06:00:17 UTC
s/SystempPopertiesAdvanced.exe/SystemPropertiesAdvanced.exe
Comment 39 V Stuart Foote 2016-11-05 06:33:59 UTC
Issues with these sm nodes extend far into the OOo past, but they took a turn for the worse on Windows with adjustments for DirectWrite and OpenGL, and some general font handling.

With the bright shinny HarfBuzz common layout in place--the miscalculations of these nodes has become _very_ obvious. 

Attachment 128423 [details] and attachment 128424 [details] from bug 60268 show the current situation with the new common layout and the default GDI and OpenGL rendering.

The issue is programmatic in the way the nodes are laid out and the scaling of the root glyph and placement of the elements is calculated.

@Takeshi--could you take a fresh look at this?

=-refs-=
size of the nodes, and placement
http://opengrok.libreoffice.org/xref/core/starmath/source/node.cxx#673
http://opengrok.libreoffice.org/xref/core/starmath/source/node.cxx#708

structure of the root and nroot
http://opengrok.libreoffice.org/xref/core/starmath/inc/node.hxx#523
http://opengrok.libreoffice.org/xref/core/starmath/inc/node.hxx#683
Comment 40 V Stuart Foote 2016-11-05 06:52:00 UTC
Moving importance to highest/critical, strongly argue that this needs correction coincident with release of the HarfBuzz common layout at 5.3.0 as this long present wart is now malignant.

Not addressing it would harm reputation of the HarfBuzz implementation (we know it is not at fault, but that is what users will believe).

/me getting off my soap box now...
Comment 41 V Stuart Foote 2016-11-05 07:10:26 UTC
Here is a simple formula to enter:

nroot{3}{27 over 2} cdot sqrt{9}

Try it with the new common layout, with and without OpenGL rendering enabled. Nodes composing a ROOT or NROOT with an OVER disrupt calculations/placement of the elements.  

The new HarfBuzz common layout is consistent in scale and position of layout--but there is masking/z-order at play with OpenGL compared to GDI rendering.
Comment 42 Khaled Hosny 2016-11-05 12:04:26 UTC
IMO LibreOffice math rendering is broken by design, no amount of bug fixing is going to fix the root issues, it needs to be redesigned and rewrote. Marking this critical or not changes nothing unless there is someone going to do the work.
Comment 43 V Stuart Foote 2016-11-05 12:33:15 UTC
All true, but I am really hoping that the issue with composing the nodes-- scaling and placing the elements for the ROOT NROOT as modified when an OVER is included--is _just_ being garbled at the moment because we have unintentionally changed a condition of the algorithm(s).  

Unfortunately I can't follow the code to figure out how the nodes are being composed (it is not documented that I can follow). So, hoping there is still an active dev who knows where to find the design notes for these, and is able to spot what has gone amiss. 

Short of scrapping it all and re-implementing, need to answer why the radix is not meeting its overbar we create, and why the bounding box for the whole node is not being honored as we scale and place elements. And why we see such difference between the GDI and the OpenGL rendering.
Comment 44 Khaled Hosny 2016-11-08 15:16:52 UTC
The HarfBuzz part is a duplicate of bug 103725, so removing the dependency from here since the old bug is unrelated to HarfBuzz.
Comment 45 V Stuart Foote 2016-11-08 15:47:19 UTC
(In reply to Khaled Hosny from comment #44)
> The HarfBuzz part is a duplicate of bug 103725, so removing the dependency
> from here since the old bug is unrelated to HarfBuzz.

OK, that is fair. And suspect that when scaling and rotation can be corrected in the Direct-Write renderer both the GDI+ and OpenGL rendering will have the math formula nodes back to more usable values with the new layout engine.
Comment 46 V Stuart Foote 2016-11-21 17:52:34 UTC
*** Bug 104092 has been marked as a duplicate of this bug. ***
Comment 47 Xisco Faulí 2016-11-27 22:21:55 UTC
*** Bug 104208 has been marked as a duplicate of this bug. ***
Comment 48 V Stuart Foote 2017-03-08 23:00:27 UTC
Commit replacing DirectWrite with GDI glyph scaling with OpenGL rendering, done for bug 103831, also did some good here for composing nodes with nroot, sqrt, or over constructs.

Closing this, with comment that there remains work needed with our DirectWrite Direct2D support that will have to be checked against this.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4375eefb644d03ab4bafbc091436166a8494dc91&h=libreoffice-5-3
Comment 49 V Stuart Foote 2017-03-08 23:04:33 UTC
Sorry, that was testing on Windows 8.1 Ent 64-bit with
Version: 5.3.2.0.0+
Build ID: a990b46ccc788db45ff4d8f0d47b799782ecb2af
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2017-03-08_19:18:26
Locale: en-US (en_US); Calc: CL

Waiting on a build of master on Windows to turn as the TBs can be updated to VS2015, but suspect it is acceptable there as well.
Comment 50 V Stuart Foote 2017-04-03 17:58:35 UTC
*** Bug 106930 has been marked as a duplicate of this bug. ***
Comment 51 V Stuart Foote 2017-06-13 17:12:43 UTC
*** Bug 108502 has been marked as a duplicate of this bug. ***