Created attachment 136443 [details] sample So the height of text in cells a1 (calibri) and a3 (times new roman) has changed in 5.3 and above compared to 5.2 and below. I am assuming its a regression caused by fixing of bug 55469 (commit:34d7602954d4483b3bc9db700e7df2c15348947a), as disabling harfbuzz in 5.3 still shows the problem. @Xisco, @Aron: Either of you have the time to bibisect this?
Created attachment 136444 [details] ms 2013 vs 6.0 vs 5.2 vs 3.6 (windows)
Created attachment 136446 [details] 6.0 vs 5.2 vs 4.0 (linux) unlike on windows, on linux only calibri has a problem, and its line spacing was decreasing over time.
(In reply to Yousuf Philips (jay) from comment #1) > Created attachment 136444 [details] > ms 2013 vs 6.0 vs 5.2 vs 3.6 (windows) For calibri, there is a 3px difference per line, while for times new roman, there is a 2px difference per line. Version: 6.0.0.0.alpha0+ Build ID: 7315f325ff7ada3d6bd85a471058fdaeaff8cdb0 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-17_06:58:21 Locale: en-US (en_US.UTF-8); Calc: group
@Jay, * Opening a sheet in calc, or table in writer, you get a cell height as recorded into the ODF (or as filter imported from OOXML). The text also receives a font and point size assignment from the ODF (or import filter). So, the table cell on opening will not resize. But text string will recalculate its vertical height as extracted from its font metric. Calculating that height at a given point size is what changed at 5.3 (for bug 55469), and was just tweaked at 5.4.2 and current master by Caolan (for bug 107249). Point is--there is no size relationship between the table cell and its contained text string other than what was calculated when the table cell was originally formatted. As font metric is read and the text string re-rendered into the table cell it can end up breaking at different places as the canvas is zoomed in or out. The string matches or it doesn't, and IIUC the actual table cell height and width dimension suffers some of the same rounding issues as now fixed font height, and that rounding manifests when zooming the cells on canvas. Seems the thing to correct here is scaling the table cell to avoid shifting the wrap point, and not the other way round with font handling. To me, this is another twist on the issue Thomas put forth in bug 112497, that is that the line spacing in table cells is now being correctly (and consistently) calculated against the font metric cross platform and it has some effect on the UI. Not wrong (assuming fidelity of the font metric) but changed. Height differences between Linux and Windows builds can occur because of divergent font metrics between the hhea and OS/2, one gets used in Linux/macOS the other in Windows.
(In reply to V Stuart Foote from comment #4) > So, the table cell on opening will not resize. But text string will > recalculate its vertical height as extracted from its font metric. > Calculating that height at a given point size is what changed at 5.3 (for > bug 55469), and was just tweaked at 5.4.2 and current master by Caolan (for > bug 107249). The point of this bug is to state that the change and tweak still has a bug in it that is visible in the rendering of both calibri and times new roman fonts. I will upload another image to clearly show this, if it isnt already evident. > Height differences between Linux and Windows builds can occur because of > divergent font metrics between the hhea and OS/2, one gets used in > Linux/macOS the other in Windows. From my test on both windows and linux, attachment 136443 [details] has the same line heights on both OSes.
Created attachment 136454 [details] writer vs calc The screenshot shows that calc is rendering the Calibri 11pt text with a smaller line spacing than the same text renders in writer, while it renders Arial with the exact same line spacing in both apps.
Created attachment 136522 [details] Calc-Writer comparison with additional fonts Additionally to Jay's fonts, I've tested the following: Row 5 - Palatino Linotype 11pt Row 6 - Courier New 11 pt Row 7 - DejaVu Sans 11 pt Row 8 - Futura-Book 11 pt (proprietary) Row 9 - Liberation Sans 11 pt Row 10 - SimSun 11 pt (it's used e.g. for Chinese) 5, 7, 8 and 10 have are differently displayed in Calc and Writer.
Created attachment 136523 [details] Resources for Calc-Writer comparison with additional fonts (odt+ods)
OT: (In reply to V Stuart Foote from comment #4) > The string matches or it doesn't, and IIUC the actual table cell height and > width dimension suffers some of the same rounding issues as now fixed font > height, and that rounding manifests when zooming the cells on canvas. Does this mean that table cell height and width calculation may need a fix similar to what was done for line spacing calculation/font rendering and that such fix would void some zoom issues? Is there a specific bug report for that existent? Zooming seems got worse since OOo times.
(In reply to Thomas Lendo from comment #7) > Row 8 - Futura-Book 11 pt (proprietary) This looks bad in both writer and calc and would suggest filing another bug for this one, as it could be something within the font that is being overlooked in the new harfbuzz rendering. (In reply to Thomas Lendo from comment #9) > Does this mean that table cell height and width calculation may need a fix > similar to what was done for line spacing calculation/font rendering and > that such fix would void some zoom issues? Is there a specific bug report > for that existent? Zooming seems got worse since OOo times. The bug i can think of regarding the zooming issue is a regression from 3.5 (bug 108638).
Created attachment 136694 [details] 5.0 vs 6.0 I can't reproduce the problem -> a1, a2 and a3 have the same line spacing from my point of view
The content of attachment 136694 [details] has been deleted for the following reason: obsolete
Ok, I installed calibri font on Ubuntu and the line spacing changed after 34d7602954d4483b3bc9db700e7df2c15348947a. However, i'm wondering if it's similar to to bug 107605 or bug 107888. @Khaled, could you please comment ?
Created attachment 136703 [details] carlito writer vs calc Just like how it affects calibri, it also affects the metrically compatible font carlito as well.
Hello Yousuf, This commit just landed in master -> https://cgit.freedesktop.org/libreoffice/core/commit/?id=9bc39be417a4c436cbe18391fc87e5e835551b07 we should try we a build having this commit
Xisco: Khaled's patch was to fix fonts that had broken line spacing, which Calibri and Times New Roman dont, so that patch wont solve this issue. There is something wrong with Calc's code to generate line spacing as Writer generates the line spacing correctly for these fonts.
(In reply to Yousuf Philips (jay) from comment #16) > Xisco: Khaled's patch was to fix fonts that had broken line spacing, which > Calibri and Times New Roman dont, so that patch wont solve this issue. There > is something wrong with Calc's code to generate line spacing as Writer > generates the line spacing correctly for these fonts. Does setting "Use printer metrics" in Calc affect the spacing? If so, a difference between line height scaling for WYSIWYG with Use printer metrics enabled or disabled in Calc, but otherwise line scaling on canvas is always enabled with Writer? See bug 108638
Created attachment 136781 [details] metrics off
Created attachment 136782 [details] metrcis on
not much difference using 'Use printer metrics' or not
part of this puzzle is probably (or at least to complicate this some more) "external leading", in writer this can be turned off and on by tools->options->writer->compatibility->"do not add leading (extra space) between lines of text"
*** Bug 113111 has been marked as a duplicate of this bug. ***
** 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
Still reproducible. Version: 6.2.0.0.alpha0+ (x64) Build ID: 425af6845ebe066c950b0b63f50563e067485f3e CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-09_23:30:22 Locale: de-AT (de_AT); Calc: CL
Dear Yousuf Philips (jay) (retired), 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
Dear Yousuf Philips (jay) (retired), 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug