Created attachment 160369 [details] Character Spacing text LO Writer 6.4.3.2 versus MS Word 365 I noticed a while ago that font spacing in Writer was a bit irregular compared to Microsoft Office Word when using the same fonts. I decided to perform a few tests to compare the character spacing in several sans serif fonts (open source or proprietary) I did the following: 1 - Open Word 365 and Writer 6.4.3.2. 2 - Write the same text with Liberation Sans, Carlito, Dejavu Sans, Noto Sans, Source Sans Pro, Roboto, Calibri and Segoe UI. 3 - Disable OpenGL rendering in Writer and compare again. 4 - Save files in both .odt and .docx. 5 - Open both .odt and .docx file in Word and Writer. 6 - Compare character spacing. The character spacing in Writer is completely inconsistent within the same word. I highlighted a few of the issues I found with the tested font types, both with OpenGL turned On and Off.
Created attachment 160370 [details] Character Spacing text LO Writer 6.4.3.2 versus MS Word 365 OpenGL off
An user on Reddit had the same issue. https://www.reddit.com/r/libreoffice/comments/gduk4n/bad_font_renderig_spacing_between_letters/?utm_medium=android_app&utm_source=share
Similar problems have been reported as bug 128987 and bug 123182 before.
Thank you. I must mention the following: I tried several zoom levels: 120%, 130%, 110%, 100% and this kept happening. The problems with character kerning (didn't know that was the word) happens in multiple font types. All of them sans serif. This is a very serious bug for anyone that wants to use Writer as a text editor. Character kerning is of the utmost importance to produce documents.
Pedro, could you please attach your sample document? That would reduce work for everybody who wants to reproduce the bug. Thanks.
Created attachment 160594 [details] Sample file with different fonts Sure, here it is the .odt file.
(In reply to Pedro from comment #6) > Created attachment 160594 [details] > Sample file with different fonts > > Sure, here it is the .odt file. Tested with your document in Version: 6.3.5.2 (x64) Build-ID: dd0751754f11728f69b42ee2af66670068624673 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded and in Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: en-GB Calc: CL but couldn't reproduce it.
(In reply to Pedro from comment #6) > Created attachment 160594 [details] > Sample file with different fonts > > Sure, here it is the .odt file. So it's a ODT document? what makes you think the issue is in LibreOffice and not in MSO Word ?
(In reply to Xisco Faulí from comment #8) > So it's a ODT document? > what makes you think the issue is in LibreOffice and not in MSO Word ? Xisco, I don't understand your question, because attachment in comment 0 and comment 1 show the rendering problems of an odt-file in writer. So MS Word is only for comparison.
You can literally check the problem in kerning spacing in the Writer file I attached. I tried it in LibreOffice 7.0 (clean user profile), in my 6.4 install and this issue appears in both. It appears in Writer with odt files and docx files. In Word it does not happen with either. Do you want me to check in Softmaker Office and WPS Office as well? There are multiple other bug reports about kerning issues around but they were different and less comprehensive than what I checked.
(In reply to Dieter from comment #7) > (In reply to Pedro from comment #6) > > Created attachment 160594 [details] > > Sample file with different fonts > > > > Sure, here it is the .odt file. > > Tested with your document in > > Version: 6.3.5.2 (x64) > Build-ID: dd0751754f11728f69b42ee2af66670068624673 > CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; > Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE > Calc: threaded > > and in > > Version: 7.0.0.0.alpha1+ (x64) > Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac > CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: > win; > Locale: de-DE (de_DE); UI: en-GB > Calc: CL > > but couldn't reproduce it. Damn it. You don't have irregular kerning? :/ I have both in 6.4 and 7. Here's the info of my LO installs: Versão: 6.4.3.2 (x64) ID da versão: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 Processos do CPU: 8; SO: Windows 10.0 Build 18363; Gestão da interface: padrão; VCL: win; Configuração regional: pt-PT (pt_PT); Idioma da interface: pt-PT Calc: threaded Version: 7.0.0.0.alpha0+ (x64) Build ID: 97a2c1fc5e376c0c00968f17a0392c6d3a5ed565 Processos do CPU: 8; SO: Windows 10.0 Build 18363; Gestão da interface: Skia/Raster; VCL: win; Locale: pt-PT (pt_PT); Idioma da interface: pt-PT Calc: threaded
(In reply to Pedro from comment #11) > Damn it. You don't have irregular kerning? :/ > I have both in 6.4 and 7. I've only checked your examples and all looks good. While writing this answer, I'm getting the idea, that it might depends on zoom level of the document (I haven't tested this). Could you please test it? Have you also teted kerning in printed document? => NEEDINFO
Created attachment 160682 [details] Zoom level 100% I'll attach a bunch of different zoom levels. I see this problem at all zoom levels. I can't test printing at home (don't have a printer). When I get to work I'll print a test document, and check if the kerning is also defective. I'll scan the result.
Created attachment 160683 [details] Zoom level 120%
Created attachment 160684 [details] Zoom level 140%
Created attachment 160685 [details] Zoom level 180%
(In reply to Pedro from comment #13) > I can't test printing at home (don't have a printer). Thanks for testing differen zoom-levels. Perhaps you can test with PDF-Export instead of printing and add result as attachment.
Created attachment 160686 [details] Word Zoom level 100% Word Zoom levels for comparison. Note the difference in Carlito on the word "testing".
Created attachment 160687 [details] Word zoom level 120%
Created attachment 160688 [details] Word zoom level 140%
Created attachment 160689 [details] Word zoom level 180%
Created attachment 160690 [details] PDF export zoom 100 Here go the pdf exportsat different zoom levels. The kerning errors are exported. I'll also upload pdf from Word for comparison
Created attachment 160691 [details] PDF export zoom 140
Created attachment 160692 [details] PDF export zoom 100 MS Word
Created attachment 160693 [details] PDF export zoom 140 MS Word Look at the word "testing" in Carlito and Calibri in Word and Writer pdf files. That's the most shocking and easy to see for me. I'm at a meeting now so I can't point out the kerning errors in detail.
Dieter, if you need something else please ask. If someone else could check this and associated bugs to try and replicate, it would be very helpful.
Created attachment 160710 [details] Screenshot of sample ODT on Windows 10 with 7.0.0 alpha1 (In reply to Pedro from comment #26) > If someone else could check > this and associated bugs to try and replicate, it would be very helpful. Here is a screenshot of the sample file displayed in LO Writer 7.0.0 alpha1 on my system, 130% zoom level. Version: 7.0.0.0.alpha1 (x64) Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU 线程: 2; 操作系统: Windows 10.0 Build 18363; UI 渲染: Skia/Raster; VCL: win; Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded I'm seeing kerning problems in completely different places than where Pedro sees them, which I also highlighted with red underlines. As for the word "testing" in the Carlito line, I do get the same look as attachment 160682 [details], but it doesn't bother me too much. I'd like to also point out that in attachment 160369 [details] it looks different again, and specifically the kerning between t and i part.
The kerning error in "testing" is just the one that is immediately easier for me to pick up on and that shows consistently in all zoom levels that I tried. The other ones for me bother me a lot more. Some words feel like they were broken down in two.
[Automated Action] NeedInfo-To-Unconfirmed
Ming Hua just confirmed this as well.
Created attachment 161030 [details] Another example of awful kerning at default zoom. Another example of awful kerning at default zoom.
I decided to check the latest version of Open Office and it also presents kerning issues just as LibreOffice does. This seems to be something inherent to the codebase of both.
(In reply to Pedro from comment #32) > I decided to check the latest version of Open Office and it also presents > kerning issues just as LibreOffice does. This seems to be something inherent > to the codebase of both. In 7.0.0.3 there are some large improvements! Some kerning issue remain and these are much more visible at 120% zoom level. Maybe that might help detect the problem?
Pedro, can you "update" the set of attachments to only have those relevant to LO 7 or later? Also, is this an issue on Windows only, or on all platforms?
Also worth checking: whether there is any difference between Skia and default rendering (to switch, Tools > Options > LibreOffice > View > Use Skia for all rendering). Version 7.0 switched to use Skia by default on Windows, which may explain the improvement Pedro saw.
Created attachment 176606 [details] Screenshot on Linux (KDE) at 180% This kerning issue has been present since when I started using LibreOffice. On Linux it also happens, at least on KDE (using Kf5). See the screenshot I've just added, where I highlight 2 instances of kerning inconsistency. Using the same words result in different kerning. Open the attached image and zoom in a lot and you'll notice many differences in spacing between characters. For instance, the distance between a and u in "default", but there is also difference between e and f in "default" as well (and in many other places). Version info: Version: 7.2.3.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.2.3~rc2-0ubuntu0.21.10.1~lo1 Calc: threaded
Isn't this just another example of https://bugs.documentfoundation.org/show_bug.cgi?id=103322 — "Use floating point for glyph positioning in VCL" reported by none other than Khaled Hosny in 2016. Depending on the zoom, DPI and other factors rounding errors cause glyphs to jump and kerning gets destroyed. A crazy example is given there where the word California looks like Califomia!!! This awful glyph position issue is why I cannot use Writer for writing, the kerning really disrupts reading and this only affects LibreOffice on any platform (I see the same on Linux and macOS). This seems like such a fundamental layout bug I am surprised it remains rattling around...
(In reply to Iandol from comment #37) > Isn't this just another example of etc. Well, is it? I mean, are you saying that this is all attributable to fraction rounding inconsistencies?
This improved a lot with Caolán's fix in bug 144862. Let's consider this fixed in 7.4. There might be specific cases that are still there, please open a separate bug report if there is any. *** This bug has been marked as a duplicate of bug 144862 ***