Bug Hunting Session
Bug 118221 - Calc fails to render (default setting) kerning=off for cells with no character formatting (leads to bad type face and bad digit alignment) [Comment 23]
Summary: Calc fails to render (default setting) kerning=off for cells with no characte...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.0.3.2 release
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:6.2.0 target:6.1.0.1
Keywords: bibisected, bisected
: 107250 (view as bug list)
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2018-06-18 09:39 UTC by OfficeUser
Modified: 2018-08-08 18:38 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Kerning_Calc.ods (9.05 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-06-18 09:40 UTC, OfficeUser
Details
Kerning_Calc.png (63.08 KB, image/png)
2018-06-18 09:41 UTC, OfficeUser
Details
Kerning_Calc_after_pressing_F2.png (196.22 KB, image/png)
2018-06-18 11:11 UTC, OfficeUser
Details
Kerning Test Table.ods (16.82 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-06-18 14:23 UTC, OfficeUser
Details
Demonstration Video (1.55 MB, application/octet-stream)
2018-06-18 14:34 UTC, OfficeUser
Details
Kerning Test Table 2.ods (17.06 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-06-19 07:52 UTC, OfficeUser
Details
Kerning Test Table 2.png (good with line break) (83.91 KB, image/png)
2018-06-19 07:57 UTC, OfficeUser
Details
red_has_kerning_on.png (38.78 KB, image/png)
2018-06-22 10:03 UTC, OfficeUser
Details
1 vs other digits (5.2.0.4 / 5.3.0.3 / 6.1 beta2) (22.90 KB, image/png)
2018-06-26 19:32 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description OfficeUser 2018-06-18 09:39:27 UTC
Description:
- Please open the attached "Kerning_Calc.ods"

- Note: You can see that the type face (centered positions of A and Ü in lines one upon the other) is identical bad for both cases, kerning turned on and off.

- Now select cell A2 and and press F2 (in order to enter edit mode)

- Note: After now the letter A is centered perfectly in relation to the Ü.

- Press ESC in order to leave the edit mode.

- Note: A and Ü are no longer "centered"

- If you try the same with cell A4 (instead of A2) you will see that also in edit mode the letters are not centered.


Conclusion:
Kerning "off" is only applied in cell edit mode. Screen, paper and PDF are affected by this bug.

Steps to Reproduce:
.

Actual Results:
.

Expected Results:
.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 OfficeUser 2018-06-18 09:40:41 UTC
Created attachment 142846 [details]
Kerning_Calc.ods
Comment 2 OfficeUser 2018-06-18 09:41:05 UTC
Created attachment 142847 [details]
Kerning_Calc.png
Comment 3 OfficeUser 2018-06-18 11:11:07 UTC
Created attachment 142853 [details]
Kerning_Calc_after_pressing_F2.png
Comment 4 OfficeUser 2018-06-18 11:11:23 UTC
Added attachment:
Kerning_Calc_after_pressing_F2.png
Comment 5 OfficeUser 2018-06-18 11:13:07 UTC
(For additional information refer to Bug 118184.)
Comment 6 OfficeUser 2018-06-18 11:14:51 UTC
For a better understanding of this issue you should notice that Arial font is better rendered with kerning turned off. See also Bug 118184.
Comment 7 OfficeUser 2018-06-18 11:18:52 UTC
@Khaled: May I kindly ask you to confirm this (new) report?
Comment 8 Heiko Tietze 2018-06-18 11:25:42 UTC
Rows 2 and 3 move a few pixels to top and right in edit mode while 4 and 5 just go up. Although we likely do not need to talk about the edit mode in Calc, but I never get A and the Ü perfectly aligned, same as in bug 118184 and also with Calligra.

Version: 6.0.4.2
Build ID: 6.0.4-2
CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

(Could try with master and 5.2.7 too...)
Comment 9 OfficeUser 2018-06-18 11:55:42 UTC
@Heiko: For simplification I did NOT write about the move up. I am only interested in the move to the right. This only happens for cells with kerning on. And it exactly matches the "good" rendering for Arial which is achieved in Writer (and MS Word) when kerning is off.

That's why I am absolutely sure that there is definitely something overwriting the kerning setting to "on" while not in cell edit mode.

(Regarding Calligra. It looks like there is no way to turn off kerning in Calligra. That's why we always see "bad" rendering in Calligra. In MS Word Arial rednering becomes bad when turning on kerning. They have it off by default.)
Comment 10 OfficeUser 2018-06-18 12:18:52 UTC
Additional information: Calc is the only LibreOffice app where kerning=off has no effect (apart from cell edit mode). In Writer, Draw and Impress it works as expected.
Comment 11 V Stuart Foote 2018-06-18 12:51:02 UTC
IIRC the Formula Bar frame (F2 to focus) gets different handling from the cell rendering on sheet, maybe a question for Eike or Kohei. Similar to content of a Text box when rendered to canvas or when being edited.

Otherwise have you toggled the "Use printer metrics for text formatting" (Tools -> Options -> LO Calc -> General: Input settings) for its  affect on text rendering in cells?

And LO ability to correct this in some fashion remains impacted by lack of floating point glyph positioning, bug 103332
Comment 12 OfficeUser 2018-06-18 14:23:51 UTC
Created attachment 142864 [details]
Kerning Test Table.ods
Comment 13 OfficeUser 2018-06-18 14:24:54 UTC
I have added the attachment "Kerning Test Table.ods" that contains special kerning-critical strings. Now everyone should be able to reproduce the bug. Steps are in the ODS file.
Comment 14 OfficeUser 2018-06-18 14:34:34 UTC
Created attachment 142865 [details]
Demonstration Video
Comment 15 Khaled Hosny 2018-06-18 16:36:20 UTC
I can confirm this.

In non-edit mode the setting to disable kerning is ignored. This because Calc has a shortcut for text layout that does not use EditEngine when certain conditions are met (for performance, I think), and when EditEngine is not used the kerning setting seem to be ignored.

This can be confirmed by forcing the variable bUseEditEngine to true in sc/source/ui/view/output2.cxx. I’m not familiar enough with Calc to know how to check if kerning is disabled and either set bUseEditEngine to true or make sure the alternate text layout path respects the setting.
Comment 16 Heiko Tietze 2018-06-19 07:31:20 UTC
Eike, what do you think?
Comment 17 OfficeUser 2018-06-19 07:51:55 UTC
@Khaled: Thanks for your investigation and explanation.

I have one more interesting finding. If the cell contains at least one CTRL+RETURN line break, the kerning=off setting is correctly rendered also in non-edit mode! Perhaps this forces the EditEngine to be used?

I have attached " Kerning Test Table 2.ods".

Compare the rendering of the cells B13 and B14. You can see that the identical string in B14 is expanded compared to B13. This indicates that kerning=off is correctly applied in this case.
(I think with this example you have the requested way to check, if kerning=off is applied.)

Would it be a solution to force EditEngine to be used always?
Comment 18 OfficeUser 2018-06-19 07:52:42 UTC
Created attachment 142904 [details]
Kerning Test Table 2.ods
Comment 19 OfficeUser 2018-06-19 07:57:57 UTC
Created attachment 142905 [details]
Kerning Test Table 2.png (good with line break)
Comment 20 OfficeUser 2018-06-19 08:00:08 UTC
(This finding finally explains why our Calc printouts often have bad type face but not in multi-line cells.)
Comment 21 Khaled Hosny 2018-06-19 08:48:04 UTC
(In reply to OfficeUser from comment #17)
> @Khaled: Thanks for your investigation and explanation.
> 
> I have one more interesting finding. If the cell contains at least one
> CTRL+RETURN line break, the kerning=off setting is correctly rendered also
> in non-edit mode! Perhaps this forces the EditEngine to be used?

I think so.
Comment 22 OfficeUser 2018-06-19 08:55:12 UTC
In case someone is ready to do a bibisect I suggest the following way:

- Use the attached "Kerning Test Table 2.ods"
- In each LO build compare the string width of B13 with B14
- If you find a build where the width is identical for both cases you found a "good" build.

(Additional info: I already have tested 5.2 without success. 5.2 should be a pre-HarfBuzz build. So it seems not HarfBuzz-related.)
Comment 23 Eike Rathke 2018-06-19 12:11:14 UTC
(In reply to Heiko Tietze from comment #16)
> Eike, what do you think?
As Khaled already explained correctly in comment 15, the EditEngine is not always used, only if cell content contains inline formatting, fields, spell-check errors, line breaks, ..., or text is rotated. For all simple strings (text, numbers, formula results) the string is fed to OutputDevice for performance reasons. Using EditEngine unconditionally is not the way to go.

Additionally, kerning attributes are kept only at EditEngine text objects, there are no cell format kerning attributes. What might be possible is for non-EditEngine cells tell OutputDevice to force kerning off via SalLayoutFlags::DisableKerning (I didn't track how exactly we call OutputDevice draws there). Just a quick idea..
Comment 24 V Stuart Foote 2018-06-19 12:41:30 UTC
Again, what effect of enabling "Use printer metrics for text formatting"? Allow that to impose overhead. 

As now, seems we only impose overhead when cell is actively being edited (w/F2) or as noted with multi-line cell content.

Suspect flushing all cell content through edit engine just to provide layout kerning is going to impose considerable performance drag.

If we have to pick performance over typeseting fidelity--99.9% of users are going to demand performance.
Comment 25 OfficeUser 2018-06-19 13:47:58 UTC
@Stuart:
> "Suspect flushing all cell content through edit engine just to provide layout kerning is going to impose considerable performance drag.

Are there any values for a performance degrade available if using EditEngine always?

> What might be possible is for non-EditEngine cells tell OutputDevice to force kerning off via SalLayoutFlags::DisableKerning (I didn't track how exactly we call OutputDevice draws there).

Is this possible to change per character? We need to keep in mind that we are talking of a character attribute (like bold, underlined, ...).
Comment 26 OfficeUser 2018-06-19 13:49:26 UTC
The second question from my comment above is for Eike.
Comment 27 Eike Rathke 2018-06-19 20:00:05 UTC
(In reply to OfficeUser from comment #25)
> @Stuart:
> > "Suspect flushing all cell content through edit engine just to provide layout kerning is going to impose considerable performance drag.
> 
> Are there any values for a performance degrade available if using EditEngine
> always?
I did a short stress testing right now, =1 formulas in narrow (optimal width) columns to have as many columns as possible to paint filling a screen width, 5000 rows, jump to end, hold PageUp to scroll to row 1: takes 5 seconds; compiled to force EditEngine takes 30 seconds.

> > What might be possible is for non-EditEngine cells tell OutputDevice to force kerning off via SalLayoutFlags::DisableKerning (I didn't track how exactly we call OutputDevice draws there).
> 
> Is this possible to change per character? We need to keep in mind that we
> are talking of a character attribute (like bold, underlined, ...).

As said in my previous comment, for inline formatted content (i.e. per character attribution) already EditEngine text is used.
Comment 28 OfficeUser 2018-06-20 11:41:15 UTC
Hi Eike,

thanks you for clarification.


> > What might be possible is for non-EditEngine cells tell OutputDevice to force kerning off via SalLayoutFlags::DisableKerning (I didn't track how exactly we call OutputDevice draws there).

I fear it will be difficult to find someone who can work on this topic. May I ask you to continue with finding a possible solution?
Comment 29 Xisco Faulí 2018-06-20 17:52:49 UTC
(In reply to OfficeUser from comment #22)
> In case someone is ready to do a bibisect I suggest the following way:
> 
> - Use the attached "Kerning Test Table 2.ods"
> - In each LO build compare the string width of B13 with B14
> - If you find a build where the width is identical for both cases you found
> a "good" build.
> 
> (Additional info: I already have tested 5.2 without success. 5.2 should be a
> pre-HarfBuzz build. So it seems not HarfBuzz-related.)

Following these steps, the kerning changed after https://cgit.freedesktop.org/libreoffice/core/commit/?id=ded07624096183ed310187f29d4692bb39b7d24a
Comment 30 OfficeUser 2018-06-21 07:08:38 UTC
Hi Xisco,

thank you very much!

Could you please tell me the latest build that includes the patch you have identified? I would like to examine how exactly it behaves regard kerning in Calc.
Comment 31 OfficeUser 2018-06-22 09:26:13 UTC
TEST RESULT
===========

Version: 4.4.7.2
Build-ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Gebietsschema: de_DE.UTF-8

==> Result: Kerning is ALWAYS applied, also when set to off.
Comment 32 OfficeUser 2018-06-22 09:39:20 UTC
TEST RESULT
===========

Version: 5.2.7.2
Build-ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10
CPU-Threads: 8; BS-Version: Linux 4.4; UI-Render: Standard; VCL: gtk2; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

==> Result: Kerning is ALWAYS applied, also when set to off.
Comment 33 OfficeUser 2018-06-22 09:43:39 UTC
CORRECTION for both test cases above:

KERNING IS ALWAYS **ON**
Comment 34 OfficeUser 2018-06-22 09:46:01 UTC
@Khaled: What has been the exact purpose of your patch?
Comment 35 OfficeUser 2018-06-22 09:51:08 UTC
I think I found a simple approach for a solution. I will come up with more details soon.
Comment 36 OfficeUser 2018-06-22 10:01:54 UTC
@Khaled

Please try the following steps.

- Enter the following string into Cell A1 and B1: AVAVAVAV
- In B1 select the first to characters AV and apply kerning=on in the character settings to them

Result: All following characters in B1 are correctly rendered with kerning=off!

You can recognize kerning=off if you can draw a vertical line between A|V which means that they are aligned by there bounding boxes. I will add a screenshot where the red colored characters have kerning=on applied.


Discussion of these findings:

- It looks like your patch is "good".

- An additional fix is needed:
In case of the whole cell content is kerning=off (default) the formatting seems to be a cell-formatting, not a character-formatting. (The same applies for bold, italic, and so on.) The problem is that the cell-formatting kerning=off is NOT fed to OutputDevice while the character-formatting IS.
Comment 37 OfficeUser 2018-06-22 10:03:17 UTC
Created attachment 143028 [details]
red_has_kerning_on.png
Comment 38 OfficeUser 2018-06-22 10:05:30 UTC
@Eike: I am looking also forward to your statement. :-)
Comment 39 OfficeUser 2018-06-22 15:07:22 UTC
@Khaled, @Eike

I guess it should be possible to fed cell-formatting kerning=off to the output device since we know that character-formatting kerning=off is correctly fed to the OutputDevice.

What do you mean? Maybe this is "only" some kind of parsing stuff to be fixed?
Comment 40 Aron Budea 2018-06-25 01:10:44 UTC
Is this the same as bug 107250?
Comment 41 OfficeUser 2018-06-26 18:44:30 UTC
*** Bug 107250 has been marked as a duplicate of this bug. ***
Comment 42 OfficeUser 2018-06-26 18:44:30 UTC
@Aron: Yes, it is.
Comment 43 Aron Budea 2018-06-26 19:32:35 UTC
Created attachment 143147 [details]
1 vs other digits (5.2.0.4 / 5.3.0.3 / 6.1 beta2)

I'll leave this screenshot here, then. Would be great to have the numbers align again.
Comment 44 OfficeUser 2018-07-01 11:04:47 UTC
I have to revoke my words regarding "cell-formatting" in Comment 36. I think this was nonsense.
Correct is that applying any simple formatting (for example bold) to a single character helps to render kerning=off correctly. This behavior is in accordance with Eike's Comment 23 because any character formatting forces the EditEngine to be used instead of the OutputDevice.


Aron Budea: If the most left screenshot is from 5.2.0.4 I cannot reproduce it. In 5.2.0.4 kerning is ALWAYS on and even cannot be turned off by applying any character formatting. So the digits are always bad aligned. It looks like Khaled's patch has improved the situation for newer builds so that kerning=off works at least for EditEngine.

But we need an additional patch to handle kerning=off also vie OutputDevice.

(@Aron: Try to apply bold to any character, and you have good digit alignment in recent builds.)
Comment 45 Khaled Hosny 2018-07-01 11:46:29 UTC
(In reply to OfficeUser from comment #44)
> I have to revoke my words regarding "cell-formatting" in Comment 36. I think
> this was nonsense.
> Correct is that applying any simple formatting (for example bold) to a
> single character helps to render kerning=off correctly. This behavior is in
> accordance with Eike's Comment 23 because any character formatting forces
> the EditEngine to be used instead of the OutputDevice.
> 
> 
> Aron Budea: If the most left screenshot is from 5.2.0.4 I cannot reproduce
> it. In 5.2.0.4 kerning is ALWAYS on and even cannot be turned off by
> applying any character formatting. So the digits are always bad aligned. It
> looks like Khaled's patch has improved the situation for newer builds so
> that kerning=off works at least for EditEngine.
> 
> But we need an additional patch to handle kerning=off also vie OutputDevice.
> 
> (@Aron: Try to apply bold to any character, and you have good digit
> alignment in recent builds.)

Not that EditEngine will eventually call OutputDevice, so the problem is not in oOutputDevice itself but in the Calc code that calls it directly. Namely it should set the kerning off on the font being used, per the settings, before processing the text with OutputDevice.
Comment 46 Khaled Hosny 2018-07-01 17:36:43 UTC
(In reply to Khaled Hosny from comment #45)
> (In reply to OfficeUser from comment #44)
> > I have to revoke my words regarding "cell-formatting" in Comment 36. I think
> > this was nonsense.
> > Correct is that applying any simple formatting (for example bold) to a
> > single character helps to render kerning=off correctly. This behavior is in
> > accordance with Eike's Comment 23 because any character formatting forces
> > the EditEngine to be used instead of the OutputDevice.
> > 
> > 
> > Aron Budea: If the most left screenshot is from 5.2.0.4 I cannot reproduce
> > it. In 5.2.0.4 kerning is ALWAYS on and even cannot be turned off by
> > applying any character formatting. So the digits are always bad aligned. It
> > looks like Khaled's patch has improved the situation for newer builds so
> > that kerning=off works at least for EditEngine.
> > 
> > But we need an additional patch to handle kerning=off also vie OutputDevice.
> > 
> > (@Aron: Try to apply bold to any character, and you have good digit
> > alignment in recent builds.)
> 
> Not that EditEngine will eventually call OutputDevice, so the problem is not
> in oOutputDevice itself but in the Calc code that calls it directly. Namely
> it should set the kerning off on the font being used, per the settings,
> before processing the text with OutputDevice.

Note*
Comment 47 Eike Rathke 2018-07-03 10:47:49 UTC
Taking a stab at this.
Comment 48 Commit Notification 2018-07-03 15:13:03 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=36eed54d3dfed6551fd2ad944feff7e217c56e82

Resolves: tdf#118221 whole cell kerning default is off

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 49 Eike Rathke 2018-07-03 15:14:15 UTC
Pending Jenkins build for 6-1 https://gerrit.libreoffice.org/56877
Comment 50 Commit Notification 2018-07-03 21:30:42 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bb1ab5c4456526e2411ba8f953e41daef8b429b&h=libreoffice-6-1

Resolves: tdf#118221 whole cell kerning default is off

It will be available in 6.1.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 51 OfficeUser 2018-07-12 13:52:01 UTC
Can confirm fixed in:

Version: 6.2.0.0.alpha0+
Build ID: 8e9d43546c8e46ea635472ddf07f5c183dc13360
CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-07-12_01:06:03
Locale: de-DE (de_DE.UTF-8); Calc: group threaded


@Khaled: Thank you very much for your dev support!

@Eike: Thank you very much for writing the final patch!
Comment 52 OfficeUser 2018-08-08 18:38:29 UTC
In addition I can confirm that this issue is fixed in:

Version: 6.1.0.3 (x64)
Build-ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU-Threads: 2; BS: Windows 10.0; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: CL