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)
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
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.
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
Created attachment 124438 [details] OpenGL log Here is that log.
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.
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.
(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
(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
OK, thanks. Yes, I see it in a fresh 5.1 build.
It is by the way quite hilarious that after inserting such a formula object in a Writer document, the object has eight green handles, but every single one of them displays a "forbidden" sign when you hover the pointer over it. I hope there is already a bug filed for this misfeature.
(I just filed such a bug myself.)
(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.
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'
I now notice that some recent change to the 5.1 branch has fixed this... and in master, too. Resolving as WORKSFORME.
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.
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.
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?
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
*** Bug 100190 has been marked as a duplicate of this bug. ***
@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.
(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
*** Bug 100645 has been marked as a duplicate of this bug. ***
Created attachment 125950 [details] sqrt and over nodes for formula with OpenGL
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.
*** Bug 101031 has been marked as a duplicate of this bug. ***
*** Bug 101883 has been marked as a duplicate of this bug. ***
*** Bug 102254 has been marked as a duplicate of this bug. ***
Correcting status to NEW, as no commits.
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.
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
(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 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).
(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.
(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?
(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
(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.
(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.
s/SystempPopertiesAdvanced.exe/SystemPropertiesAdvanced.exe
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
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...
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.
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.
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.
The HarfBuzz part is a duplicate of bug 103725, so removing the dependency from here since the old bug is unrelated to HarfBuzz.
(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.
*** Bug 104092 has been marked as a duplicate of this bug. ***
*** Bug 104208 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 106930 has been marked as a duplicate of this bug. ***
*** Bug 108502 has been marked as a duplicate of this bug. ***