Created attachment 101313 [details] example of the bug Create new text field Enter some text in it to make it several lines Make some letters in this text "subscript" Result: Uneven line spacing in the paragraph... It has been fixed in Writer some time ago, but Impress still shows such behavior.
Strange... Uploaded png file became (plain/text)...
Created attachment 101314 [details] Proper example of the bug
Can you please attach a zip of two test files 1) writer (fixed) 2) impress (nit fixed) so this can effectively be tested. After providing that, please set the bug back to UNCONFIRMED. Thanks
Created attachment 103542 [details] odp and odt files with subscript examples
Reproduced with LO 4.3.0.3, 4.2.6.2, 3.3.0.4 - Ubuntu 12.04 x86 AOO 4.1.0 as well Seems the default value of "Raise/lower by" is 33%. I think it should be around 1-5% like in Writer.
** 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.0.5 or 5.1.2 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Re-tested... Version 5.0.5.2 – the behavior is the same Updated to 5.1.2.2 – also exactly the same I've tested some values... To prevent uneven lines, the default value for "lower by" for subscript should be less than 10%... Like in Writer... However, Writer sets the flag "Automatic" for the value... Setting the same flag in Impress makes an issue even worse... Subscript and superscript should never affect the distance between lines, even if they overlap with the text above or below... If that happens, it's the user's responsibility to increase the line interval...
** 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.2.7 or 5.3.3 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-20170522
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The bug is still present in 6.0.4.2 If you enter a lot of text in a text field, and that text contains subscripts here and there (which is common for scientific presentations), the whole text looks very ugly because of the uneven distances between lines. Paragraph rendering should work the same way as in Writer. There is no such issue in Writer.
Dear Eliot the Cougar, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Just checked this issue again in 6.2.5.2 The issue is still present i.e. the gap between the line that contains subscript and the line below it is wider than normal. When there is a text with a lot of subscripts here and there (common for scientific presentations), the overall text column looks bad.
Make sure whoever looks at this focuses on SUBscripts, not SUPERscripts, which are fine. I tried to find out when "Writer fixed subscripts" but I don't see changes since 2001, and Writer already worked fine in LO 3.5 which is as far back as I can test. There are calculations that I can't understand at all at SwSubFont::CalcEscAscent in sw/source/core/txtnode/swfont.cxx. Perhaps those can help someone. The main point is that automatic subscripting should not drop lower than the font's descent or bottom line...
#define DFLT_ESC_SUB -33 // also 1/3 previously 8/100 which is not clearly indicated when this happened, but I first see it in 2007 with https://cgit.freedesktop.org/libreoffice/core/commit/?id=1982c6b8ec96b793ee5461a984e2fbc40caa6342
Bug 95272 seems to be a duplicate of this one here. Can someone please try to fix this in the next 10 years? (I think I've reported this bug 10 years ago to the OpenOffice bug tracker...) Just for the record: This behavior is still the same in the current LibreOffice version 6.3.2.2.
Created attachment 156157 [details] File showing the uneve3n line spacing with subscripts
I would rate the importance as "major" (It seems that as a "normal" user I cannot change the importance; I got an error message when trying to do so) Reason: One cannot make a proper presentation in any case where subscripts appear in the text, such as in chemistry (chemical formulae like H2O all have subscripts). The uneven line spacings look absolutely ugly. With fixed line spacing (in the paragraph format dialog), superscripts are fine, but subscripts shift the whole line up. See attached file. I do not agree with comment 5 that the default "raise/lower" should be reduced. Instead, the line spacing must not be modified when it is set to "fixed".
Proposed fixes so far: https://gerrit.libreoffice.org/c/core/+/88910 tdf#80194 UI: revert subscript DFLT_ESC_SUB to 8% (from 33%) https://gerrit.libreoffice.org/c/core/+/88911 tdf#80194 editeng: fix auto subscript calculations (In reply to Anastasius from comment #18) > With fixed line spacing (in the paragraph format dialog), superscripts are > fine, but subscripts shift the whole line up. See attached file. None of my fixes will be related to "fixed line spacing". If you use ridiculous values for superscript (like 400%) or set it to automatic, I think you will see that superscript is actually not fine. It is just that the default value is appropriate. > I do not agree with comment 5 that the default "raise/lower" should be > reduced. Actually, that is the key to the whole fix. Only 20% of the font height is available for subscript-shifting while the remaining 80% is available for superscript. So subscripts need to lower a much less percentage than superscripts can or should. Another fix needed is to set the "automatic" flag to superscript/subscript when it is set using the toolbar .uno:SubScript. However, I want to wait with that until the next release (7.1) because older versions will calculate auto very wrongly (see comment 7's note that "Setting the automatic flag in Impress makes the issue even worse...").
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5f4a65b7a3a29972c90a5ef4eb5fd7795b205cdf tdf#80194 UI: revert subscript DFLT_ESC_SUB to 8% (from 33%) It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/94a3ac2b6f89aeac5b947034eb4d7e63838218e3 related tdf#80194 editeng RTF: set automatic subscript for \sub It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Justin L from comment #19) > Another fix needed is to set the "automatic" flag to superscript/subscript I tested export/import of automatic to various formats in order to test whether automatic would be problematic for compatibility. In summary, I don't think that any fixes should be necessary. ODT, ODS, ODP, ODG: as expected, these all import and export fine. DOC/DOCX textboxes: these do not round-trip the auto-flag, but convert actual font sizes and adjust to an appropriate escapement. No problems here. XLS/XLSX: these do not round-trip the auto-flag. At least in Excel 2003 there is no choice for fontsize or escapement, just subscript=on/off. So it just saves/loads default values. No problems here. PPT: this does not round-trip the auto flag, but does save escapement percentage. At least in PowerPoint 2003 there is no choice for fontsize, only escapement. And the fontsize seems to be static, no matter what escapement is chosen. Since AUTO exports default values, no problems here. PPTX: similar to PPT except that it does round-trip AUTO, which is fine.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2940d1905b921d9909b08b1e32014d3c44474ef0 tdf#80194 editeng: fix auto subscript calculations It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Is this issue fixed, Justin?
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/888cff8bb0326153415b1d64d1ca6a45ac3ae84c tdf#80194 proof search: assert to find proof of code correctness. It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Justin L from comment #19) > Another fix needed is to set the "automatic" flag to superscript/subscript This won't really be valuable unless LO first implements a font-metric based calculation to find the best position based on each font's specific characteristics. That would be a worthy goal (after all, that is what Writer does), worthy of a separate bug report.
Created attachment 158786 [details] subscriptReport.zip: source files for the Release Notes content
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0f29d36aa9e6ac7d0914a6e1749c16ecec216904 tdf#80194 autoEsc: use fontmetrics in calculation It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 160173 [details] How FontBasics.svg look on my system (In reply to Justin L from comment #27) > Created attachment 158786 [details] > subscriptReport.zip: source files for the Release Notes content Did anyone get the FontsBasics.svg file in this zip working? Attached is a screenshot of how it looks like in Firefox on my Windows 10 system. Other picture viewers give similar results, i.e. lots of elements missing and it doesn't look like FontBasics.png at all. I need a proper SVG file so that I can translate it for the explanation picture ( https://wiki.documentfoundation.org/File:SubscriptReport_7.0.png ) in the release note.
(In reply to Justin L from comment #27) > Created attachment 158786 [details] > subscriptReport.zip: source files for the Release Notes content The last paragraph contains different sentence between the file and the PNG file in the Wiki. File: "The calculation for determining automatic positioning was also fixed for Textboxes. Before, it used the entire 42% to both raise and lower - which was way too much. Now it uses 80% and 20% respectively." Wiki: "The calculation for determining automatic positioning was also fixed for Textboxes. Before, it used the entire 42% to both raise and lower - which was way too much. Now, just like the Writer, it uses the font's real ascent and descent to calculate optimal position." Which one the right sentence? *and why on earth this should be a DOC file. :(
(In reply to Rizal Muttaqin from comment #30) > Which one is the right sentence? The one on the dynamic wiki is the up-to-date sentence. The one in the static upload to bugzilla is the obsolete one. (The end result is basically the same thing, so I'm not too worried about any documentation errors. This changed is documented in the summary of https://wiki.documentfoundation.org/File:SubscriptReport_7.0.png, but of course that is hard to find/notice.)
I was surprised to see a formatting change in my impress slide sets when I upgraded to 7.0.0. My index relative font size is 80% and I manually lowered indices by 20%. As of 7.0.0 the automatic lowering by 8% was set everywhere. This is not good for symbols like, e.g. n_0, where a relatively large letter is the index of a relatively small one. I see that there has been a long dispute on this bug. Maybe it would be better not to enable Automatic raise/lower by default. The old settings were still there and I could re-activate them by switching off Automatic. I luckily had an old macro in my backup to fix all the indices. Is there a way to turn of automatic raise/lower by default, maybe somewhere in the settings?
(In reply to Gizze from comment #32) > My index relative font size is 80% and I manually lowered indices by 20%. > As of 7.0.0 the automatic lowering by 8% was set everywhere. I would not expect that a document that saved as non-automatic would import as automatic. Please create a new bug report and attach a simple, sample document.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d384ccdb04ebeb8b094e6d9a2ddf4e5aea5327c8 related tdf#80194 SvxEscapementItem: set auto flag as default It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.