Created attachment 173010 [details] screenshot of problem caused by pair kerning **Description:** I was trying to hunt down the source of the (for me) long-time crappy font rendering in LibreOffice writer. I found https://bugs.documentfoundation.org/show_bug.cgi?id=103322 and initially thought that was the issue, but it turns out to be more complicated. With most common fonts, the rendering gets *significantly* better when I disable pair kerning. The following discussion references the attached screenshot. Both renderings have flaws in character positioning (they're kerned incorrectly, which doesn't imply that the bug is necessarily in the kerning implementation). My understanding is that this is probably caused by https://bugs.documentfoundation.org/show_bug.cgi?id=103322 However, with pair kerning enabled, the kerning immediately becomes *incredibly* bad, so much so that Writer sucks to write in. I currently write text in a different editor and copy it over when I need to use LibreOffice. Some flaws are so obvious they will be immediately apparent even to those who know nothing about font rendering. See "Earth" and "signifying" in Minion Pro, "dwelt" in Arial, "met" in Garamond, and many other examples. (A few pairs are better with pair kerning enabled, which suggests that maybe it's not completely broken?) **System Information:** * OS: Arch Linux * Kernel: 5.10.44-1-lts * LibreOffice: 7.1.4-1 (libreoffice-fresh Arch package) * Display Server: X11 * Pango: 1.48.5 * Desktop Environment: KDE * Fontconfig settings: hinting disabled, subpixel anti-aliasing enabled, dpi=120 **Other:** This might be the cause of https://bugs.documentfoundation.org/show_bug.cgi?id=128987 but I can't tell because I don't use Windows. Another possibility is that enabling pairwise kerning greatly exacerbates the effect of https://bugs.documentfoundation.org/show_bug.cgi?id=103322 at least on certain systems / monitors (non-default DPI settings?). If that's the case, it probably needs to be disabled by default until that bug is fixed. Text in LibreOffice *looks* like it might be hinted to me (it's hard to tell when the rendering is broken), which would be a problem / bug because I have hinting disabled in fontconfig. I'm not sure how much of the problem might be due to poor hinting. Elsewhere, users have reported bugs that look as if they might be caused by this issue: https://askubuntu.com/questions/827033/libre-office-font-spacing-kerning-issue Incidentally, PDFs exported from LibreOffice look great, the bug doesn't affect that.
Follow up: Looking at https://bugs.documentfoundation.org/show_bug.cgi?id=103322 again, it's worth pointing out that if I'm reading the following correctly, LibreOffice is not using subpixel positioning at all. > We should switch to using floats to store glyph positions instead, which would make the rounding errors less visible. It would also allow us to benefit from sub-pixel positioning support in the graphics libraries we use. Indeed, from testing this appears to be the case. If you look at the screenshot I'm about to attach, you'll see that each glyph on the first line has exactly the same subpixel offset as the corresponding glyph on the second line. This isn't the case with a properly behaving FreeType renderer (tested in KWrite). That's why the result of that bug is a bunch of bad glyph positioning problems. If you type a repeated character like "mmmmmmm", the text layout engine will (in 12 pt Arial) put each "m" slightly too close together because it lacks subpixel positioning. Eventually it has to fix the word length and so it puts a extra 1 pixel gap between two "m"s. Looks ugly: https://bugs.documentfoundation.org/show_bug.cgi?id=88991 The thing is, so long as LibreOffice doesn't support subpixel positioning, it's not surprising that pair kerning might make these rendering issues much worse. Most kerning operations are relatively subtle, and when your renderer doesn't support subpixel positioning at all, it's not surprising that that the engine goes nuts and gives you nonsense results (like characters colliding) when asked to make small adjustment to the glyph position. If that turns out to be what's happening here, I think that's a further argument for defaulting it to off.
Created attachment 173023 [details] Screenshot showing lack of subpixel positioning Screenshot shows 12pt Arial rendered at 100% zoom in LibreOffice. Screenshot was run through a script that shows subpixels in a 3x3 grid and then point upscaled 5x. Identical glyphs have the same subpixel offset.
Created attachment 173480 [details] Screenshot of similar comparison under Windows (In reply to adam.m.fontenot+docfo from comment #0) > This might be the cause of > https://bugs.documentfoundation.org/show_bug.cgi?id=128987 but I can't tell > because I don't use Windows. I don't know much about text rendering so all I can add is a screenshot with 7.2.0 Beta1 on Windows 10, showing similar differences with or without pair kerning.
Unfortunately there don't seem to be LO developers actively working on text rendering right now. Let's see if the UX team want to have a look at this and discuss the possibility of turning off pair kerning by default. The advantage seems not clear-cut to me, and I don't think it's possible to turning it off only for certain fonts. For people not familiar with pair kerning: The option to turn it on/off is located at the "Position" tab of the character formatting or paragraph style dialog.
Cross platform we went to harfbuzz at 5.3.0.3; any improvement to sub-pixel rendereing needed to improve font provided hinting for kerning will only come with resolution of bug 103322
Might be not so easy to switch kerning off for every PS and CS. But thanks for the bug report. Wish each would be as clear as this.
(In reply to Ming Hua from comment #3) > I don't know much about text rendering so all I can add is a screenshot with > 7.2.0 Beta1 on Windows 10, showing similar differences with or without pair > kerning. Thanks for your effort to get this looked at. The issue with using Windows as a comparison is that by default Windows hints so strongly that much of the subpixel nuance is lost anyway. I actually find the screenshot you posted very difficult to read because of the amount of distortion to the glyph shapes. IIRC, the developers of Microsoft Word agree with me, and they actually wrote their own text rendering engine for Word so that they don't have to use ClearType. (It's been a long time since I looked at anything Windows related, I could be misremembering.) (In reply to V Stuart Foote from comment #5) > Cross platform we went to harfbuzz at 5.3.0.3; any improvement to sub-pixel > rendereing needed to improve font provided hinting for kerning will only > come with resolution of bug 103322 This was indeed what I was worried about. My thinking, though, is that this bug shouldn't depend on that one. If LibreOffice doesn't support rendering at arbitrary subpixel offsets, then pair kerning (which depends heavily on being able to render at precise offsets) is sort of useless / broken. As far as I can tell, in LibreOffice's present state, pair kerning is effectively adding or subtracting a small random value from the desired glyph offset, which then gets rounded by the renderer into whole pixels. It's really not surprising that the result is frequently worse than no pair kerning at all. For that reason, it seems to make sense to consider disabling it until bug 103322 is fixed. Can anyone show that having it enabled confers any definite advantage to font rendering under Linux at present? My screenshots of LibreOffice's rendering would seem to suggest that the results of having it enabled are uniformly worse.
This was introduced with https://bz.apache.org/ooo/show_bug.cgi?id=16874. But let's give it a try to disable this option by default https://gerrit.libreoffice.org/c/core/+/119168
Pair kerning is for high quality typesetting. It's a de facto standard in document editing, not only in desktop publishing. Disabling kerning for better low resolution rendering in LO would be a regression, because the reported problem doesn't affect document publishing, while disabling kerning will result worse documents, see e.g. broken "Te", "To" letter pairs in the attached examples. Printing (which is still the main target of document editing) is correct. Also digital publishing is correct: see the attached animated gif kern_pdf.gif, which shows the PDF export (with and without kerning) in subpixel-based rendering by Poppler using the PDF viewer "evince". Also I attached screenshots about the Writer problem for comparison, see kern.gif (61% zoom) and kern2.gif (200% zoom) in a 1920×1200 pixel LCD display. As a workaround for the reported problem, enable "View PDF after export", so clicking on the PDF export icon, you can see the result with subpixel-based rendering, too. By the way, kerning is environment-friendly, because it results less pages for printing. It seems, in MSO 2016, kerning is disabled for the new documents (maybe this is not true for newer MSO versions), so LO is "greener" with its default kerning, than MSO.
Created attachment 173704 [details] sub-pixel based PDF rendering in Evince with and without kerning
Created attachment 173705 [details] rendering in Writer with and without kerning (200% zoom)
Created attachment 173706 [details] rendering in Writer with and without kerning (61% zoom) (these and the screenshots of the previous animated gifs were rendered for an 1920×1200 pixel LCD display)
What a pity that we have no simple solution. If you insist in disabled pair kerning, please uncheck it for the Default Paragraph Style, save as template and make this the default for new documents.
(In reply to László Németh from comment #9) > Pair kerning is for high quality typesetting. It's a de facto standard in > document editing, not only in desktop publishing. Thanks for your comment. I was surprised to see a commit reverting this so quickly and in fact I was going to raise the issue of rendering to PDF myself. Indeed, I'm worried that a naive solution that simply changes the default would break high quality PDF rendering. (This hadn't yet occurred to me when I made the suggestion.) > As a workaround for the reported problem, enable "View PDF after export", so > clicking on the PDF export icon, you can see the result with subpixel-based > rendering, too. Yes, this is exactly the workaround I've been using when writing anything in LibreOffice for years now. Write a few paragraphs without proofreading them, export to PDF, then read back the PDF. That's the only way to avoid a miserable experience trying to edit/read a document in LibreOffice at the moment. Although I'm sure you're aware of this, I want to be clear that the status quo is very bad. A huge number of LibreOffice users have complained about its font rendering over the last few years, and so I was surprised to learn that there's seemingly no active effort to fix the complete lack of subpixel positioning for glyphs in the editor. --- As I said above, I do agree that simply disabling the pair kerning default isn't acceptable because of high quality printing and PDF output. But I still don't think this should be a WONTFIX - there's another alternative. Leave pair kerning enabled but only apply the setting to output that actually *can* be meaningfully kerned - i.e. only the contexts which support accurate subpixel positioning. So you will continue to get the high quality desktop publishing output, while the LibreOffice editor component which handles font rendering will silently ignore the setting when rendering text (for example, in the Writer window). Alternatively, I request that a separate setting be added to disable pair kerning *only* in the editor components while leaving it enabled for desktop publishing cases. I'd also point out that if casual users discover that having pair kerning enabled makes their documents look worse, they will simply disable it, heavily reducing the quality of their published documents. Writer is a WYSIWYG editor after all! --- I'm reopening the bug so that the proposal above can be discussed. I apologize if reopening a closed bug is against etiquette on this issue tracker - this is my first issue opened here.
It remains an issue of available precision, the rounding errors and coarseness of glyph placement onto a pixel based screen canvas can not physically do much better compared to the print and PDF export which have much higher precision (and where font kerning is functional). Addressing bug 10332 would allow effective sub-pixel rendering and more appealing font kerning on displays. Until then while substituting fonts, the 'Always' or 'Screen Only' choices on the Tools -> Options -> Fonts 'Replacement Table' demonstrates a precedent for handling rendering to VCL screen canvas distinct from printing/PDF generation. I have not looked at the methods, but imagine similar mechanism could be applied to font kerning--just a reversed sense, 'Never' or for 'Printing/PDF Only' output. Maybe even located on the same Tools -> Fonts panel as it should be applied globally.
László has some strong arguments in comment 9. But anyway, no UI/UX change required, removing the keyword.
*** Bug 145583 has been marked as a duplicate of this bug. ***
I was reminded of this bug because another bug was just marked as a dupe of it. Wanted to comment that the dupe provides a good example of the point I was making: the user was reporting that kerning was bad on macOS, and that pair kerning seemed to make it much worse. It's not unlikely that this user went on to disable pair kerning (at least for certain fonts), ruining the quality of their published / printed documents. No doubt other users are doing the same, although they may never see this bug report. I think that's the situation we need to avoid. I think V Stuart Foote made a good point in https://bugs.documentfoundation.org/show_bug.cgi?id=142940#c15 > Addressing bug 10332 would allow effective sub-pixel rendering and more appealing font kerning on displays. Fixing that bug would certainly fix this bug as well. However, the reason this bug exists is that there's seemingly been no movement whatsoever on that bug in *years* now. I think it is fair to say that there is virtually no interest in fixing it. This bug arises from that fact. Disabling pair kerning on the screen canvas would improve the quality of rendering in the interim, until that bug is fixed. Doing so is likely to be *much* easier than thoroughly replacing the glyph positioning code throughout LO to use floating point. Would a patch that disabled pair kerning *only* on the screen canvas without providing a corresponding toggle to enable it be acceptable, or is a setting a necessity? Trying to work out what I could conceivably contribute here, as someone unfamiliar with the LO codebase.
I agree with Adam. We know that pair kerning makes the screen rendering awful, but the print output better. We also can reasonably guess that no one is ever going to fix bug 10332. Thus, the solution is: * Disable pair kerning for screen rendering * Enable pair kerning for print * Remove the preference
Created attachment 178784 [details] animation showing behavior with and without pair kerning I was poking around with this bug some more and discovered something quite strange. I'm hoping someone can help me understand it and suggest whether filing a separate bug report for it would be worthwhile. The attachment shows the issue. The images in the GIF are subpixel antialiased and then re-rendered in grayscale using the RGB value of each subpixel. (The result is point upscaled 3x for clarity.) The transition from "no pair kerning" to "pair kerning" makes sense, because it illustrates this bug. Pair kerning makes things worse when subpixel positioning isn't supported. The transition from plain Cairo to Cairo with subpixel positioning disabled also makes sense, because it illustrates why the lack of subpixel positioning in LibreOffice (bug 103322) is such a big problem. But the transition from Cairo with no subpixel positioning to LibreOffice is very strange! They're *similar*, but the position of the two "a" characters is pretty bad in LibreOffice. This seems to suggest that LibreOffice has another glyph positioning bug - not only does it not support subpixel positioning, it frequently doesn't even pick the best *pixel* position, despite Cairo doing so. Is this a different issue than bug 103322? I'd be happy to report it.
I believe this text shaping issue and bug 103322 will now get some attention with the TDF tender [1] (contracted development) just let to Collabora. @Michael M. could you comment here? =-ref-= [1] https://blog.documentfoundation.org/blog/2021/12/08/tender-to-optimize-text-layout-performance-for-print-and-pdf-export-202112-01/
V Stuart - best to CC Miklos I guess; he leads the TDF tender work.
The above tender focuses on performance, which implicitly means the expectation is that no behavior changes, just the text layout will be done faster. However, Caolan recently worked on improving the result of text layout, see bug 144862. Does that help here? I haven't checked in detail.
(In reply to Miklos Vajna from comment #23) > However, Caolan recently worked on improving the result of text layout, see > bug 144862. Does that help here? I haven't checked in detail. I was able to sort-of test this by downloading a nightly from the 7.3 branch and one from the latest master. I was able to repro this issue on the 7.3 branch, but not the master branch. The changes you linked seem like the most plausible candidate for having fixed this. In fact, font rendering on 7.4 is significantly better than just fixing this one issue would suggest. *Subpixel positioning* appears to be working, which isn't even supposed to be possible (if my understanding of bug 103322 is correct). But I am definitely seeing different subpixel alignments for the same glyph. Maybe someone knows how? I'm honestly blown away by the improvement. Kudos. In the 7.4 nightly, enabling pair kerning generates a clear improvement as expected - small corrections to letter spacing behave exactly as expected. To confirm that this issue is fixed and not some mistake on my part, it would be nice to be able to isolate the commits that fixed it, but it looks like not all the commits involved in adding the new glyph positioning mode are linked in bug 144862. Could these be identified? (I might even backport them so that I don't have to wait for a beta to use the new glyph positioning code.)
A relevant commit is https://cgit.freedesktop.org/libreoffice/core/commit/?id=4ed26badfd6fd9190cb6e54078b41eb38cb37dca which removed the most offending problem, that of using the https://wiki.openoffice.org/wiki/Writer/WYSIWYG heuristic to reconcile between low-screen positions and hi-res printer positions in favor of using just the hi-res printer positions and push the problem down to the glyph rendering where the various destination OS/graphic-libs tend to have some sort of options to handle that better. That old workaround had a multiplier for kerning toggled on vs off which is where the difference with that enabled/disabled came from.
Created attachment 178879 [details] full backport to 7-3 for the interested
(In reply to Caolán McNamara from comment #26) > Created attachment 178879 [details] > full backport to 7-3 for the interested Finally had time to build this and I'm very happy to report that it works! The changes you made fixed most of the issues with font rendering and also thereby fixed this issue where kerning makes things worse. Thanks for the backport. I'm very grateful for your work on this issue. LibreOffice is usable for me once again, after years of doing my writing in another editor.
Verified as per comment #27.