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:
Created attachment 142846 [details] Kerning_Calc.ods
Created attachment 142847 [details] Kerning_Calc.png
Created attachment 142853 [details] Kerning_Calc_after_pressing_F2.png
Added attachment: Kerning_Calc_after_pressing_F2.png
(For additional information refer to Bug 118184.)
For a better understanding of this issue you should notice that Arial font is better rendered with kerning turned off. See also Bug 118184.
@Khaled: May I kindly ask you to confirm this (new) report?
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...)
@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.)
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.
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
Created attachment 142864 [details] Kerning Test Table.ods
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.
Created attachment 142865 [details] Demonstration Video
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.
Eike, what do you think?
@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?
Created attachment 142904 [details] Kerning Test Table 2.ods
Created attachment 142905 [details] Kerning Test Table 2.png (good with line break)
(This finding finally explains why our Calc printouts often have bad type face but not in multi-line cells.)
(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.
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.)
(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..
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.
@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, ...).
The second question from my comment above is for Eike.
(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.
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?
(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
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.
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.
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.
CORRECTION for both test cases above: KERNING IS ALWAYS **ON**
@Khaled: What has been the exact purpose of your patch?
I think I found a simple approach for a solution. I will come up with more details soon.
@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.
Created attachment 143028 [details] red_has_kerning_on.png
@Eike: I am looking also forward to your statement. :-)
@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?
Is this the same as bug 107250?
*** Bug 107250 has been marked as a duplicate of this bug. ***
@Aron: Yes, it is.
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.
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.)
(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.
(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*
Taking a stab at this.
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.
Pending Jenkins build for 6-1 https://gerrit.libreoffice.org/56877
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.
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!
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