Description: In LibreOffice on both Windows and Mac, some fonts such as Arial and Liberation Sans have an odd rendering/kerning quirk. The digits in these fonts normally align with one another, but when two "1"s appear next to each other, they are kerned more tightly. This does *not* appear to be related to the Pair Kerning option in Writer - the same issue appears regardless of whether Pair Kerning is set. The same rendering issue even appears in Calc, which makes columns of numbers look awkwardly misaligned when some of them contain "11" as a substring. Steps to Reproduce: 1. In either Writer or Calc, enter the following numbers, one per line, setting the font to either Liberation Sans or Arial: 123456, 121212, 212121, 111111. Actual Results: The lines all appear to be the same length. Expected Results: The first three lines are of equal length, but the last line (111111) is noticeably narrower. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 132660 [details] Writer document demonstrating the issue
Created attachment 132661 [details] Calc document demonstrating the issue
Created attachment 132663 [details] Screencap of Writer test case on MacOS Rendered using MacOS 10.12.4 and LibreOffice 5.3.2.2
Created attachment 132664 [details] Screencap of Calc test case on MacOS Rendered using MacOS 10.12.4 and LibreOffice 5.3.2.2
Created attachment 132665 [details] Screencap of Writer test case on Windows 7 Rendered using Windows 7 and LibreOffice 5.3.2.2 (both 64-bit)
Created attachment 132667 [details] Screencap of Calc test case on Windows 7 Rendered using Windows 7 and LibreOffice 5.3.2.2 (both 64-bit)
Additional note: The font files for both Arial and Liberation Sans include a kern pair for '11' in their 'kern' table. This suggests that pairwise kerning is being applied regardless of whether "use pair kerning" is enabled-- or, in the case of Calc, regardless of whether it's even an available option.
Correction/amendment to the above: the '11' kern pair in both fonts is defined in both the 'kern' and 'GPOS' tables. (Based on the comments in bug 105922, it's likely GPOS that's actually getting used here.) For contrast, Microsoft Word gives the rendering that I would have expected: "111111" is shorter than the other lines when kerning is enabled, but the same length as the other lines when kerning is disabled.
Please retest with a master/5.4.0 nightly build. This is correct there, I believe with work on bug 105454 https://cgit.freedesktop.org/libreoffice/core/commit/?id=ded07624096183ed310187f29d4692bb39b7d24a
5.4.0 nightly fixes the Writer test case, giving the same rendering as in Word (i.e., "111111" aligns if kerning is disabled). However, it does *not* fix the Calc test case. Kerning is still enabled by default there, unlike in Excel.
(In reply to Cody Boisclair from comment #10) > However, it does *not* fix the Calc test case. Kerning is still enabled by > default there, unlike in Excel. Reproduced. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 9348b322a5c230dfcc2231661b73e480b130fcd9 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on April 28th 2016
** 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 in 6.1 beta2. Let's reset importance, as proper alignment of numbers is actually significant in a spreadsheet application.
*** This bug has been marked as a duplicate of bug 118221 ***