Created attachment 126046 [details] odt files with formula rendering issues Many formula rendering issues. Partially overlaps with ticket 99231 but has new artifacts. Using a) OpenGL for all rendering and b) Force OPenGL even is blacklisted as View Options
Created attachment 126047 [details] Screenshot of first rendered page of odt tfile
Created attachment 126048 [details] Screenshot of first rendered page of odt file
Generally it's not a good idea to report bugs this way where it's a litany of issues - even if related. I'm not going to take the time to triage each one and I doubt any developer is going to tackle the bug when it's at minimum 12 bugs in one. It's much better to report individual bugs and then put "see also" to let developers know there are related issues. IMO this should be closed as INVALID as it's unlikely to move forward in this state.
(In reply to Ben from comment #0) > Using a) OpenGL for all rendering and b) Force OPenGL even is blacklisted as > View Options So does it work ok without OpenGL?
Turning OpenGL off causes the issues described in https://bugs.documentfoundation.org/show_bug.cgi?id=99231. So both settings with OpenGL cause different issues.
On my system with non-working OGL, the only problem I see is "Tau subscript cut-off" Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: 28ac6fdc11559b58ac62089300aa99530b0b822d CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-07-18_02:54:20 Locale: fi-FI (fi_FI); Calc: CL
*** This bug has been marked as a duplicate of bug 103725 ***
*** Bug 103745 has been marked as a duplicate of this bug. ***
see attachment 128722 [details] (bug 103725) for current state of layout with new HarfBuzz text layout with OpenGL and default rendering for sm math formulas. Still issues with scaling, and differences between default GDI+ rendering and OpenGL rendering. But the most annoying are with the scaling for nodes of the formula editor as can be seen in this clip.
Created attachment 128727 [details] attachment 126046 [details] opened with new layout engine on 20161113 OpenGL (l) default (r) As can be seen in the attached clip using new HarfBuzz based text layout, for sm math module formula composition, scaling for OpenGL rendering remains considerably different from default GDI+ rendering.
Adjusting this to reflect state of HarfBuzz's handling of sm math formulas on Windows builds. It provides a nice ODT sample document. Also here are a few sample starmath formulas to check progress: =-= nroot{3}{27 over 2} cdot sqrt{9} %ALPHA %PHI %OMEGA %alpha %phi %omega newline %iALPHA %iPHI %iOMEGA %ialpha %iphi %iomega newline oper %PHI from 1 to n x " " oper %iPHI from 1 to n x newline sqrt{sum from 1 to n x} " " nroot{3}{prod from 1 to n x} =-= Please point newly arriving issues for math formula scaling and composition on Windows here--with note to compare _both_ the OpenGL and default GDI+ rendering. Also to compare the new layout engine against the old DirectWrite only text layout. When/if bug 103680 to implement OpenType Math table features and a new internal formula composition this should resolve. Until then... =-QA Note-= as originally opened against 5.1.4.2 (for VCL OpenGL glyph scaling) this probably should have been resolved a duplicate of bug 99351, or even bug 32362--but have repurposed it.
Whoops forgot to add Regina's useful sm math samples showing lack of horizontal glyph scaling with the new layout engine. =-= widevec {P_0 P_1} widehat {P_0 P_1} {x+y+z} overbrace {} {x+y+z} underbrace {} =-=
Note: this issue affects just the Windows builds using DirectWrite (WinLayout) and GDI+/DirectWrite (SimpleWinLayout) with HarfBuzz. Linux with fontconfig/pango and HarfBuzz common layout have well formed results with all the sample formulas here. Version: 5.3.0.0.alpha1+ Build ID: 11cab8aba359c655a75791ddbc0f2ffeae8ce206 CPU Threads: 2; OS Version: Linux 3.10; UI Render: GL; VCL: gtk2; Layout Engine: new; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-11-06_23:07:09 Locale: en-US (en_US.UTF-8); Calc: group
And here is the StarMath notation for kompilainenn's attachment 128714 [details] formula =-= left ( sum from{k=1} to{n} a_k b_k right ) leslant left ( sum from{k=1} to{n} a_k^2 right ) left ( sum from{k=1} to{n} b_k^2 right ) =-= On the Windows builds for all these sample formulas, with either GDI+ or OpenGL rendering sm math remains correct internally--but we have a rendering issue for the glyph used in each node. That is you can see the bounding box for each node is being calculated correctly by positioning the edit cursor on the operator or before the character--in this example each of the left ( or right )--and the formula canvas will show the bounding box of node. On the Linux builds the glyphs are constrained to the bounding boxes. When rendering on Windows we scale the glyphs close to the node's vertical height but do not constrain them horizontally to the bounding box while scaling--i.e. on Windows the glyph does not stretch anisotropically to fit vertical an/or horizontal bounds of the node--on Linux we do. Additionally with OpenGL rendering we clip the scaled glyph to the node's bounding box which makes for some badly garbled formulas. A bit of a special case, the sqrt and nroot operators show a node bounding box for just the radical symbol--the overbar is then calculated to intersect the top right corner of the bounding box. With GDI+ or OpenGL the radical is simply scaled not stretched vertically to fit its bounding box.
On Windows 10 Pro 64-bit (1607) en-US with Version: 5.3.0.0.alpha1+ Build ID: 84f644eee78106f01486098d446d9163b62927eb CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-15_23:52:44 Locale: en-US (en_US); Calc: CL sm math glyph scaling with the DirectWrite OpenGL rendering with the new HarfBuzz layout is still wrong--the glyph does not stretch anisotropically to fit bounding box of the node and is cropped. sm math glyph scaling with GDI+ rendering with HarfBuzz has been reverted [1][2] to not use DirectWrite, and is now scaling glyphs to fit bounding box. Seems the DirectWrite based OpenGL rendering needs additional implementation work to resolve this and bug 99351 =-ref-= [1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=d436065bc1c68fc2d90e73253d8c00503c72dfd0 [2] https://cgit.freedesktop.org/libreoffice/core/commit/?id=a5750d92b2136d60d698b41ef5760f2efac0ffce
Yes, this is the expected result. OpenGL bugs are old and should not block HarfBuzz adoption, that is why I reverted back to GDI when OpenGL is not used, this way we have feature parity with pre-HarfBuzz code.
For bug 103831, the removal of DirectWrite Direct2D calls for scaling glyphs with OpenGL and instead using GDI calls corrects this issue as well. =-=-= All elements and nodes in the smath formulas: nroot{3}{27 over 2} cdot sqrt{9} %ALPHA %PHI %OMEGA %alpha %phi %omega newline %iALPHA %iPHI %iOMEGA %ialpha %iphi %iomega newline oper %PHI from 1 to n x " " oper %iPHI from 1 to n x newline sqrt{sum from 1 to n x} " " nroot{3}{prod from 1 to n x} newline widevec {P_0 P_1} newline widehat {P_0 P_1} newline {x+y+z} overbrace {} newline {x+y+z} underbrace {} newline left ( sum from{k=1} to{n} a_k b_k right ) leslant left ( sum from{k=1} to{n} a_k^2 right ) left ( sum from{k=1} to{n} b_k^2 right ) are rendered correctly now with OpenGL enabled. =-=-= On Windows 10 Pro 64-bit en-US 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 http://cgit.freedesktop.org/libreoffice/core/commit/?id=4375eefb644d03ab4bafbc091436166a8494dc91&h=libreoffice-5-3