Bug Hunting Session
Bug 65229 - superscript element in formula shifts formula baseline
Summary: superscript element in formula shifts formula baseline
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
3.6.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Formula-Editor
  Show dependency treegraph
 
Reported: 2013-06-01 08:42 UTC by Yury
Modified: 2019-02-24 20:31 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
screenshot (6.71 KB, image/png)
2013-06-01 08:43 UTC, Yury
Details
sample doc with 3 formulas (21.58 KB, application/vnd.oasis.opendocument.text)
2013-06-01 08:44 UTC, Yury
Details
formula baseline shifted (look at denominator line and equal sign relative placement) (36.86 KB, image/png)
2013-06-06 14:23 UTC, Yury
Details
doc for the 2nd proofpic (16.37 KB, application/vnd.oasis.opendocument.text)
2013-06-06 14:31 UTC, Yury
Details
more clear example (13.89 KB, application/vnd.oasis.opendocument.text)
2013-07-22 08:22 UTC, Yury
Details
proofpic for 4.4.2.2 and 'more clear example' from attachments (2.74 KB, image/png)
2015-04-20 06:07 UTC, Yury
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yury 2013-06-01 08:42:57 UTC
In formulas, if any superscript element is used, even an empty one (^{}) the formula's baseline is shifted down, by small but quite visible amount. That produces an unpleasant, sloppy look, especially if similar glyphs are used both in formula and text, in the same line.

Proof: sample document with three formulas and part of the screenshot, with another window titlebar (reddish block) serving as a ruler. The 1st formula has "real" superscript  (^+{}) and is shifted down, the 2nd has no superscript -- and is positioned correctly w/r to the baseline, the 3rd has empty superscript (^{}) and is shifted down.

"Line spacing" setting (default of "5%") in formula editor has no effect on this, this is obviously an added "extra", produced somewhere in rendering code.
Comment 1 Yury 2013-06-01 08:43:30 UTC
Created attachment 80111 [details]
screenshot
Comment 2 Yury 2013-06-01 08:44:16 UTC
Created attachment 80112 [details]
sample doc with 3 formulas
Comment 3 Yury 2013-06-06 14:22:50 UTC
I believe this might be related (in its cause) to the cropping of diacritical overmarks in tickets #62355 and #32417 (supposedly fixed)

Also, there's not so trivial consequence of this -- if the baseline for the rendered formula is placed arbitrary, then formula isn't really in sync with the baseline to which its frame is supposedly aligned.

Proofpic is attached -- "spot the correct baseline". Notice how denominator line and 'equal' sign are shifted relatively to each other and differently, too, in two formulas enclosed in identical 'formula' frame styles.
Comment 4 Yury 2013-06-06 14:23:58 UTC
Created attachment 80409 [details]
formula baseline shifted (look at denominator line and equal sign relative placement)
Comment 5 Yury 2013-06-06 14:31:18 UTC
Created attachment 80413 [details]
doc for the 2nd proofpic
Comment 6 Yury 2013-07-22 08:22:43 UTC
Created attachment 82807 [details]
more clear example

This demonstrates the formula's baseline shifting, quite to the loss of the output quality.

The formulas are, respectively, 
α=1 , ... , g_i
β=1, ... , g_k {}^{}

The {}^{} is added to the 2nd formula because of https://bugs.freedesktop.org/show_bug.cgi?id=62355
Comment 7 QA Administrators 2015-04-01 14:41:01 UTC Comment hidden (obsolete)
Comment 8 Yury 2015-04-01 15:50:03 UTC
Not fixed in 4.4.2.2. Baseline in the 1st formula of the "more clear" example is still definitely higher than baseline in the 2nd formula.
Comment 9 Yury 2015-04-20 06:07:19 UTC
Created attachment 114939 [details]
proofpic for 4.4.2.2 and 'more clear example' from attachments

You'd want the proof, so here goes. Xterm window used as a ruler.
Comment 10 Yury 2015-04-20 06:08:44 UTC
Would you need examples which WERE positively affected by changes in 4.4 renderer compared to the 4.3?
Comment 11 QA Administrators 2016-09-20 09:33:37 UTC Comment hidden (obsolete)
Comment 12 Yury 2016-09-20 16:37:11 UTC
Looks good/fixed in:
Version: 5.2.1.2
Build ID: 31dd62db80d4e60af04904455ec9c9219178d620
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
Locale: ru-RU (en_GB.UTF-8); Calc: group
Comment 13 Yury 2016-09-20 16:40:27 UTC
Unfortunately, the 1st example (`sample doc with 3 formulas`), though, still shows the issue (middle O(3) shifted down a little).
Version: 5.2.1.2
Build ID: 31dd62db80d4e60af04904455ec9c9219178d620
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
Locale: ru-RU (en_GB.UTF-8); Calc: group
Comment 14 Yury 2016-09-20 16:41:22 UTC
(In reply to Yury from comment #12)
> Looks good/fixed in:
> Version: 5.2.1.2
> Build ID: 31dd62db80d4e60af04904455ec9c9219178d620
> CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
> Locale: ru-RU (en_GB.UTF-8); Calc: group
...with the `more clear example` example ODT.
Comment 15 Xisco Faulí 2017-09-29 08:50:05 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice 
(5.4.1 or 5.3.6  https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and 
your operating system, and any changes you see in the bug behavior
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave 
a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug-20170929