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
Hello, Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document. (Please note that the attachment will be public, remove any sensitive information before attaching it.) How can I eliminate confidential data from a sample document? https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F Thank you
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.
Created attachment 125055 [details] printscreen No repro with 5.1.3,win7.
Bug needs confirmation before being marked as NEW. Status -> UNCONFIRMED
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)
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 " "
Created attachment 125953 [details] test file
Created attachment 125954 [details] font selection
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.
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.
Created attachment 125965 [details] screenshot of rendered formulas Added screenshot of rendered formulas per Stuart's request.
(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)
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
Created attachment 125969 [details] OpenGL rendering turned on See superscript 2 overlapping with bracket
(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.
(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.
*** Bug 102165 has been marked as a duplicate of this bug. ***
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