Bug Hunting Session
Bug 100746 - Math Formula scaling issues with new HarfBuzz text layout on Windows with DirectWrite -- OpenGL rendering
Summary: Math Formula scaling issues with new HarfBuzz text layout on Windows with Dir...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha1+
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 103745 (view as bug list)
Depends on: hb_ot_math HarfBuzz
Blocks: Formula-Editor Font-Rendering VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-07-03 22:36 UTC by Ben
Modified: 2017-03-09 01:51 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
odt files with formula rendering issues (76.50 KB, application/vnd.oasis.opendocument.text)
2016-07-03 22:36 UTC, Ben
Details
Screenshot of first rendered page of odt tfile (27.19 KB, image/png)
2016-07-03 22:40 UTC, Ben
Details
Screenshot of first rendered page of odt file (15.97 KB, image/png)
2016-07-03 22:41 UTC, Ben
Details
attachment 126046 opened with new layout engine on 20161113 OpenGL (l) default (r) (281.82 KB, image/png)
2016-11-13 15:27 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ben 2016-07-03 22:36:47 UTC
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
Comment 1 Ben 2016-07-03 22:40:14 UTC
Created attachment 126047 [details]
Screenshot of first rendered page of odt tfile
Comment 2 Ben 2016-07-03 22:41:06 UTC
Created attachment 126048 [details]
Screenshot of first rendered page of odt file
Comment 3 Joel Madero 2016-07-06 06:26:07 UTC
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.
Comment 4 Buovjaga 2016-07-16 17:18:14 UTC
(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?
Comment 5 Ben 2016-07-17 16:49:44 UTC
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.
Comment 6 Buovjaga 2016-07-18 10:54:11 UTC
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
Comment 7 V Stuart Foote 2016-11-11 16:13:53 UTC

*** This bug has been marked as a duplicate of bug 103725 ***
Comment 8 V Stuart Foote 2016-11-13 14:23:12 UTC
*** Bug 103745 has been marked as a duplicate of this bug. ***
Comment 9 V Stuart Foote 2016-11-13 14:28:16 UTC
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.
Comment 10 V Stuart Foote 2016-11-13 15:27:20 UTC
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.
Comment 11 V Stuart Foote 2016-11-13 16:31:08 UTC
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.
Comment 12 V Stuart Foote 2016-11-13 16:57:17 UTC
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 {}

=-=
Comment 13 V Stuart Foote 2016-11-14 04:37:58 UTC
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
Comment 14 V Stuart Foote 2016-11-14 15:25:51 UTC
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.
Comment 15 V Stuart Foote 2016-11-16 05:24:30 UTC
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
Comment 16 Khaled Hosny 2016-11-16 05:30:29 UTC
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.
Comment 17 V Stuart Foote 2017-03-09 01:51:30 UTC
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