Bug Hunting Session
Bug 112558 - Single line spacing of Calibri and Times New Roman no longer calculated correctly in Calc compared to Writer
Summary: Single line spacing of Calibri and Times New Roman no longer calculated corre...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.6.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering Cell-Line-Spacing Universal-Line-Spacing
  Show dependency treegraph
 
Reported: 2017-09-22 01:13 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-10-17 02:36 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
sample (20.88 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-09-22 01:13 UTC, Yousuf Philips (jay) (retired)
Details
ms 2013 vs 6.0 vs 5.2 vs 3.6 (windows) (125.52 KB, image/png)
2017-09-22 01:16 UTC, Yousuf Philips (jay) (retired)
Details
6.0 vs 5.2 vs 4.0 (linux) (85.67 KB, image/png)
2017-09-22 02:55 UTC, Yousuf Philips (jay) (retired)
Details
writer vs calc (41.37 KB, image/png)
2017-09-22 07:05 UTC, Yousuf Philips (jay) (retired)
Details
Calc-Writer comparison with additional fonts (181.01 KB, image/png)
2017-09-25 08:12 UTC, Thomas Lendo
Details
Resources for Calc-Writer comparison with additional fonts (odt+ods) (213.23 KB, application/x-zip-compressed)
2017-09-25 08:14 UTC, Thomas Lendo
Details
5.0 vs 6.0 (deleted)
2017-10-02 14:29 UTC, Xisco Faulí
Details
carlito writer vs calc (65.01 KB, image/png)
2017-10-02 17:17 UTC, Yousuf Philips (jay) (retired)
Details
metrics off (33.24 KB, image/png)
2017-10-05 14:06 UTC, Xisco Faulí
Details
metrcis on (33.10 KB, image/png)
2017-10-05 14:07 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2017-09-22 01:13:33 UTC
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?
Comment 1 Yousuf Philips (jay) (retired) 2017-09-22 01:16:08 UTC
Created attachment 136444 [details]
ms 2013 vs 6.0 vs 5.2 vs 3.6 (windows)
Comment 2 Yousuf Philips (jay) (retired) 2017-09-22 02:55:20 UTC
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.
Comment 3 Yousuf Philips (jay) (retired) 2017-09-22 04:43:36 UTC
(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
Comment 4 V Stuart Foote 2017-09-22 05:35:24 UTC
@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.
Comment 5 Yousuf Philips (jay) (retired) 2017-09-22 06:52:45 UTC
(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.
Comment 6 Yousuf Philips (jay) (retired) 2017-09-22 07:05:30 UTC
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.
Comment 7 Thomas Lendo 2017-09-25 08:12:21 UTC
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.
Comment 8 Thomas Lendo 2017-09-25 08:14:27 UTC
Created attachment 136523 [details]
Resources for Calc-Writer comparison with additional fonts (odt+ods)
Comment 9 Thomas Lendo 2017-09-25 08:42:08 UTC
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.
Comment 10 Yousuf Philips (jay) (retired) 2017-09-25 10:38:53 UTC
(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).
Comment 11 Xisco Faulí 2017-10-02 14:29:02 UTC Comment hidden (obsolete)
Comment 12 Xisco Faulí 2017-10-02 15:46:37 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2017-10-02 15:48:08 UTC
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 ?
Comment 14 Yousuf Philips (jay) (retired) 2017-10-02 17:17:28 UTC
Created attachment 136703 [details]
carlito writer vs calc

Just like how it affects calibri, it also affects the metrically compatible font carlito as well.
Comment 15 Xisco Faulí 2017-10-03 21:27:41 UTC
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
Comment 16 Yousuf Philips (jay) (retired) 2017-10-04 04:17:51 UTC
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.
Comment 17 V Stuart Foote 2017-10-04 05:28:14 UTC
(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
Comment 18 Xisco Faulí 2017-10-05 14:06:29 UTC
Created attachment 136781 [details]
metrics off
Comment 19 Xisco Faulí 2017-10-05 14:07:55 UTC
Created attachment 136782 [details]
metrcis on
Comment 20 Xisco Faulí 2017-10-05 14:08:53 UTC
not much difference using 'Use printer metrics' or not
Comment 21 Caolán McNamara 2017-10-12 08:34:37 UTC
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"
Comment 22 Julien Nabet 2017-10-14 08:51:25 UTC
*** Bug 113111 has been marked as a duplicate of this bug. ***
Comment 23 QA Administrators 2018-10-15 02:50:10 UTC Comment hidden (obsolete)
Comment 24 Thomas Lendo 2018-10-16 07:02:01 UTC
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
Comment 25 QA Administrators 2019-10-17 02:36:45 UTC
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