Download it now!
Bug 99231 - Wrong formula rendering
Summary: Wrong formula rendering
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-12 00:58 UTC by Ben
Modified: 2017-03-09 01:59 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Wrong formula rendering (6.05 KB, image/png)
2016-04-12 00:58 UTC, Ben
Details
Document with 4 formulas which get rendered incorrectly (43.28 KB, application/vnd.oasis.opendocument.text)
2016-04-16 21:33 UTC, Ben
Details
printscreen (9.22 KB, image/png)
2016-05-15 05:09 UTC, raal
Details
test file (39.99 KB, application/vnd.oasis.opendocument.text)
2016-06-28 00:20 UTC, Ben
Details
font selection (10.87 KB, image/png)
2016-06-28 00:21 UTC, Ben
Details
screenshot of rendered formulas (157.78 KB, image/png)
2016-06-28 12:55 UTC, Ben
Details
OpenGL rendering turned on (177.51 KB, image/png)
2016-06-28 16:22 UTC, Ben
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ben 2016-04-12 00:58:24 UTC
Created attachment 124263 [details]
Wrong formula rendering

Formula gets rendered wrong in LibreOffice Writer, see also attachment:
{
italic %mu sup " " sub " "
}
equiv
sum from i=1 to N
X sub i sup " "
over
N
Comment 1 raal 2016-04-12 10:42:47 UTC Comment hidden (obsolete)
Comment 2 Ben 2016-04-16 21:33:46 UTC
Created attachment 124415 [details]
Document with 4 formulas which get rendered incorrectly

See all formulas in the attached document. The i=1 and N get shifted to the right. In the last case the get shifted between the parentheses.
Comment 3 raal 2016-05-15 05:09:47 UTC
Created attachment 125055 [details]
printscreen

No repro with 5.1.3,win7.
Comment 4 raal 2016-05-15 05:10:23 UTC
Bug needs confirmation before being marked as NEW. Status -> UNCONFIRMED
Comment 5 Buovjaga 2016-05-17 11:01:16 UTC
I actually repro from scratch the situation in attachment 124263 [details], but the document shows like in raal's screenshot.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha1+
Build ID: 3d27afd26f7b85c46a7c7d08498000b9dbcea1c8
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-05-09_02:42:15
Locale: fi-FI (fi_FI)
Comment 6 Ben 2016-06-28 00:19:16 UTC
Rendering has improved in the 5.1.4.2 version, but the location of i=1 and N, below and on top of the summation sum is not correct. Both need to be centered relative to the lower and upper portion of the sigma sign and N needs to be lowered to have the same distance from the sigma sign as i=1. 

When using i and j as indices (see formula 2 in the attached doc) then the j seems to be in italic while the i is in normal format. See first attachment for all mentioned artifacts and an example of the formula below.

Also, the format of the integral symbol seems to be strange. Maybe it has a different font than the rest of the text under the integral? I used the font setting as indicated in the second attachment.

{
italic %sigma sup " " sub E
} sup 2
=
E sub 0 sup 2
sum from {i,j=1} to N
p sub i left (
%gamma sub i sup " "
-
sum from i=1 to N
p sub i %gamma sub i sup " "
right ) sup 2 sub " "
"  and  "
{
italic %sigma sup " " sub {nitalic %DELTA t}
} sup 2
=
{%DELTA t sub 0 sup 2}
sum from i=1 to N
p sub i left (
%gamma sub i sup " "
-
sum from i=1 to N
p sub i %gamma sub i sup " "
right ) sup 2 sub " "
Comment 7 Ben 2016-06-28 00:20:25 UTC
Created attachment 125953 [details]
test file
Comment 8 Ben 2016-06-28 00:21:34 UTC
Created attachment 125954 [details]
font selection
Comment 9 Ben 2016-06-28 00:30:04 UTC
An addition to mast last comment. The spacing between text before the sigma sign and the sigma sign seems to be very small. The spacing between the sigma sign and the next text is rather large. A similar observation can be made for the integral sign.
Comment 10 V Stuart Foote 2016-06-28 04:06:57 UTC
There are marked difference in rendering between OpenGL and default rendering. From your written description, assume you are using default. Please verify.

OpenGL works well except for rendering the SQRT NROOT, and when an OVER element is a component of a node--see bug 99351

Also, rather than just posting the Starmath markup--is really helpful if you provide a screen clip of the formula as rendered.  A clip made either from the OLE formula in Writer, or directly from the Math formula editor. That way we have some representation of how your system is handling the composition.
Comment 11 Ben 2016-06-28 12:55:16 UTC
Created attachment 125965 [details]
screenshot of rendered formulas

Added screenshot of rendered formulas per Stuart's request.
Comment 12 V Stuart Foote 2016-06-28 13:04:46 UTC
(In reply to Ben from comment #11)
> Created attachment 125965 [details]
> screenshot of rendered formulas
> 
> Added screenshot of rendered formulas per Stuart's request.

Thanks, OpenGL status, looks to be off?  What is result with OpenGL rendering enabled?  Tools -> Options -> View: Use OpenGL for all rendering (on restart)
Comment 13 Ben 2016-06-28 16:21:03 UTC
Stuart,

I turned on both OpenGL rendering options:
- Use OpenGL for all rendering (on restart)
- Force OpenGL even if blacklisted (on restart).

I restarted LibreOffice. This had no effect. After restarting the computer it renders very nicely.

Note that the (on restart) does not clarify whether LibreOffice of the Computer needs a restart. I would change this to say (on restart of the computer). The other thing is that upon a re-install these settings probably go back to the default: unchecked. Can they be turned on by default. I think many users forget about this even if they have set this to on in the past. Even more users may not know about this and blame improper rendering it to LibreOffice.

One issue I noticed wrt rendering is the superscript 2 which overlaps with the righthand parenthesis, see attachment. This also occurs with straight brackets
Comment 14 Ben 2016-06-28 16:22:51 UTC
Created attachment 125969 [details]
OpenGL rendering turned on

See superscript 2 overlapping with bracket
Comment 15 Buovjaga 2016-06-28 16:43:17 UTC
(In reply to Ben from comment #13)
> I restarted LibreOffice. This had no effect. After restarting the computer
> it renders very nicely.
> 
> Note that the (on restart) does not clarify whether LibreOffice of the
> Computer needs a restart. I would change this to say (on restart of the
> computer). The other thing is that upon a re-install these settings probably

It's supposed to be on restart of LibreOffice. Not sure, what glitch might have made it behave like in your case.
Comment 16 V Stuart Foote 2016-06-28 17:12:13 UTC
(In reply to Ben from comment #13)
> Stuart,
> 
> I turned on both OpenGL rendering options:
> - Use OpenGL for all rendering (on restart)
> - Force OpenGL even if blacklisted (on restart).
> 
> I restarted LibreOffice. This had no effect. After restarting the computer
> it renders very nicely.

Suspect you had an instance of LibreOffice soffice.exe/soffice.bin still running--Quickstarter perhaps. Also, I would be careful about using the Force OpenGL to bypass blacklisting.  The Devs blacklist a GPU hardware/driver combinations for a reason. If you get locked out of the UI, you can edit the stanzas in the registrymodifications.xcu in the user profile.

> 
> Note that the (on restart) does not clarify whether LibreOffice of the
> Computer needs a restart. I would change this to say (on restart of the
> computer). The other thing is that upon a re-install these settings probably
> go back to the default: unchecked. Can they be turned on by default. I think
> many users forget about this even if they have set this to on in the past.
> Even more users may not know about this and blame improper rendering it to
> LibreOffice.
> 

Restart means for LibreOffice--not the computer, just be sure all LO processes are shutdown. OpenGL is enabled by default on Windows builds but only if the GPU hardware/driver pair are *not* blacklisted.  If blacklisted--you'll need to use that checkbox. A new installation will recheck for black-list, not clear if it will change the stanza in registrymodifications.xcu

> One issue I noticed wrt rendering is the superscript 2 which overlaps with
> the righthand parenthesis, see attachment. This also occurs with straight
> brackets

Different composition depending on OpenGL rendering that uses DirectWrite based font handling, or default rendering which uses legacy GDI+. We tried Uniscribe with OpenGL for a bit, but it was too unstable and we moved to DirectWrite for OpenGL support. Unfortunately the Devs are playing 'whack-a-mole' with rendering issues with DirectWrite. And the node structures of the smath canvas are apparently very tricky to get glyphs to scale and position where needed. Handling SQRT or NROOT when OVER elements are present is quite bad (bug 99351).

We have a GSOC project ongoing looking to implement Harfbuzz (bug 89870) for the Windows font handling which with any luck will improve consistency of formula composition (assembling the nodes) on the smath canvas.

Meanwhile, best to identify specific element combinations in default and OpenGL rendering that are badly composed in Formula Editor or when OLE.  Open a separate bug for each.

In the examples here:  the positioning of the elements making up the SUMMATION-- "sum from i=1 to N", so glyph U+2211 and the from to node composition has spacing issues, should be its own specific bug.

Suggest it would be more helpful closing this issue as WORKSFORME, and instead open specifics against each formula "node" with composition issues occuring either in default GDI+, or with OpenGL rendering or especially if in both.
Comment 17 Buovjaga 2016-10-18 12:41:17 UTC
*** Bug 102165 has been marked as a duplicate of this bug. ***
Comment 18 V Stuart Foote 2017-03-09 01:59:45 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.

Rendering of sample formulas and test documents now match with OpenGL rendering and Default GDI based rendering.

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