In the screenshot below, screenshot one shows the bottom of Kickoff, while screenshot 2 shows the same words rendered correctly in KWrite. Note the spacing between letters which is consistent in the second screenshot, but not the first. For example, note the position of the letter t in the word "History". Reproducible: Always Steps to Reproduce: Look at the plasma desktop Actual Results: Font kerning is incorrect Expected Results: Font kerning should be correct Also reported to Qt as bug 49646.
Created attachment 95757 [details] Incorrect rendering
Created attachment 95758 [details] Correct rendering
As noted in the Qt bug, this seems to be similar to what happens in Qt 4 when the "native" backend is used instead of the raster backend.
Changing the font in system settings appears to fix this until Plasma is restarted. Note: By this I mean changing the font to a different font, then back to the original, so the bug is not in the font.
I've changed the version to 5.6.2, as it continues to exist in the latest release.
That's not different rendering, that's just Kate using a different font. By default kate will use a monospace font. If you're convinced there's actually a bug, please reopen and include: - your font settings - a comparison against something with the same font. For example the tab bar in kate if the file is called history
I've now attached two screenshots. Font is Clear Sans Regular size 10. "Plasma Incorrect" shows how the text is rendered in Plasma immediately after starting it. "Plasma Correct" shows the correct rendering, visible if I change the font to something else, then back to Clear Sans Regular size 10, as mentioned in comment 4.
Created attachment 99941 [details] Plasma Incorrect
Created attachment 99942 [details] Plasma Correct
Created attachment 101563 [details] Screenshot of "Digital Clock" widget settings window This screenshot clearly demonstrates the bug. Note, for example, the rendering of the word "Appearance" or "Holidays" in the tab bar. In this case I am using Clear Sans at size 10, but the issue is also visible with other fonts. In particular in the spacing between "l" and "i" in "Holidays" when using Noto Sans size 10.
In the above case, changing the font and changing it back (as in comment 4) doesn't fix the issue, since the font change is not immediately reflected in the window.
Does your freetype use any patches? Can you try changing hinting style in system settings? Since you seem the only one having the issue, I am sure it is related to your freetype configuration.
No freetype patches, hinting set to slight. With hinting set to full, the bug is harder to notice, but still exists if I look carefully.
beojan is absolutely not the only person who's been experiencing this. The bug is reproducible regardless of the specifics of one's installation and that means regardless of what font or font rendering is used. It's just that most people do not notice it, however, the pictures attached here show that it is a problem. Please confirm this bug. It's still reproducible with Plasma 5.9.4 and Qt 5.8.0
Created attachment 105080 [details] Bad kerning, default Note the gaps between "v" and "i" in the word "Devices"; and the gap between the letters "p" in "Application".
Created attachment 105081 [details] Correct kerning, non-default Note that the spacing between the letters is correct now. Proper rendering can only be triggered by changing the system fonts to different ones and then back to the desired ones. The system will boot into an environment with incorrect kerning every time.
i have this same problem in the main menu if i'm using a TTF font and it pops up with OTF fonts too but only in my Event Calendar widget past midnight (when there's a date change - I can fix the kerning by rebooting or by resizing the panel)
Created attachment 107994 [details] Adapta theme screenshot, bad kerning This happens as you resize the window with the Adapta theme
Created attachment 107995 [details] Adapta theme screenshot, good kerning As you resize the window further, the kerning problem disappears. If you continue to resize the window, it reappears. Back and forth like that.
As in the two additional screenshots I posted, proving that the kerning's out of whack with different Plasma themes on, you can recreate this problem if you try it with Adapta and keep resizing the window - the kerning turns good then bad then good, like a merry-go-round. It's not supposed to be doing that, and it does this regardless of what font's being used (and regardless if you have Kvantum on or not). This happens on the Plasma panel as well, after the clock strikes midnight and the date changes.
The screenshots only show the issue in the window decoration's title bar, right? That would be unrelated to this ticket, because those are rendered by KWin, not the Plasma shell.
Created attachment 108321 [details] New screenshot Here's another screenshot demonstrating this bug on Plasma. Given the comment above, it's possible the bug is at a deeper level (something shared between KWin and Plasma, perhaps). I'm using Intel integrated graphics on a 4700MQ processor, 1920x1080 using X11.
That would be Qt, yes. Qt uses freetype to render the text, but placement of the glyphs is more complicated. It could be influenced by DPI scaling and/or a mismatch what Qt thinks the font metrics are and what freetype actually uses. In either case, I doubt it is a Plasma or KWin bug.
Yes, you'll see I reported this to the Qt bug tracker above. However, there seems to be something about the way Plasma and Leon (really Aurorae) uses Qt that triggers this, so the investigation needs to start with Plasma.
In fact, it turns out the Aurorae KWin theme uses QML components from Plasma (specifically Plasma core), so this probably *is* a Plasma bug, rather than a Qt bug.
FWIW the actual URL of the Qt bug is https://bugreports.qt.io/browse/QTBUG-49646
Nate, could you confirm where the bug is? If not, please do not set the bug status to confirmed.
I set it to confirmed because many people are reporting it, not because I have identified the location of the problem (If I'd done that, I'd just fix it). Until we can get merge the Confirmed/Unconfirmed statuses into something else, I think we should use CONFIRMED the way our users expect, which is to mean "We know that this is a real bug even though we haven't figured out how to fix it yet." Whenever people complain in a bug "Why isn't this confirmed yet? It's been 400 years!!!!" They are using that more common definition of confirmed. It doesn't help us or them to use a more narrow pedantic definition of the term, and then explain over and over again the difference, when in point of fact, there really is no difference from the developer's perspective.
i'd hate to belabor the point, but from a layman's point of view, unconfirmed sounds like low priority and confirmed sounds like virtually fixed
(In reply to Rooty from comment #29) > i'd hate to belabor the point, but from a layman's point of view, > unconfirmed sounds like low priority and confirmed sounds like virtually > fixed my bad i'm sleep deprived, i meant to say, confirmed conveys the idea "we're working on it" as opposed to not
"It is not a universal issue, because it does not happen on every system" - cfeck There also seems to be some confusion about what the word "universal" means, albeit in a much problematic manner. Universal doesn't mean "reproducible with my settings". It means "reproducible with the settings $user used". To yet again strengthen the claim that is a universal bug, I felt compelled to install KDE Neon in a VM. This was a clean install and an entirely different distro than the one I regularly use. The bug was reproducible. Here are the clear-cut steps for reproducing it on your system: 1. Install a non-default font like Lato (if not already installed, link: http://www.latofonts.com/lato-free-fonts/) 2. Set subpixel rendering to "RGB" 3. Set hinting to "none" 4. Switch all of the fonts to the non-default one 5. ***Reboot*** (this is crucial because everything will look fine if you don't) 6. Observe the bug in the plasma-pa applet or the start menu application launcher. With this more impartial testing in KDE Neon, with Lato pt 10 bad spacing can be seen in the "History" text in the start menu, and with Lato pt 11 it was most obvious in the "Application" text in the plasma-pa applet. DPI of 96 used.
or just try resizing the plasma panel with a font other than noto sans or the Adapta theme, resizing windows and watching the titlebar go crazy all with the hinting off
(In reply to Christoph Feck from comment #27) > Nate, could you confirm where the bug is? If not, please do not set the bug > status to confirmed. p.s. CONFIRMED This bug is valid and has recently been filed. Bugs in this state becomeIN_PROGRESSwhen somebody is working on them, or become resolved and markedRESOLVED. according to this definition the bug is valid (being reproducible, consistent and universal), which also precludes the possibility of it being UNCONFIRMED. it is also neither in progress nor resolved.
I believe these last few comments support my point that CONFIRMED means something different to our users. Christoph, tou've often pointed out (e.g. in https://bugs.kde.org/show_bug.cgi?id=383753) that that KDE developers don't treat bugs differently when they're CONFIRMED vs UNCONFIRMED; that the distinction is meaningless to us. Since that's the case, until we can collapse both into one single new status, I think we ought to treat CONFIRMED to mean what our users think it means: "We know this is a bug but haven't figured hot how to fix it yet." If there are no objections to this, I will re-mark the bug as CONFIRMED.
The only way this is related to QML, Qt or Plasma is if we somehow force a wider gap between upper and lower case letters in the example provided (H and i). I don't understand why we would or why that would be visible only in a few fonts. Not saying its impossible but it feels like a fault that is only fixable by the font designer or the version of the font you downloaded. If not this would be rather easily spotted in ALL fonts
Checking into it and it can be a rendering issue, that depends on Qt - and if so (this is based on random asking around, searching for the issue online so "means nothing") its based on certain font types (like clear sans) and/or formats of fonts.
(In reply to Jens Reuterberg from comment #35) > The only way this is related to QML, Qt or Plasma is if we somehow force a > wider gap between upper and lower case letters in the example provided (H > and i). Back in the Qt4 / KDE 4 days, there was a similar bug in all Qt applications if you used the native (X11) backend. If you switched to the raster backend, that bug disappeared (but Plasma widgets were no longer anti-aliased). It was closed because the native backend was deprecated, so we can't see how it was fixed. > I don't understand why we would or why that would be visible only in a few > fonts. > It's visible in all fonts. Some fonts just have a design which makes bad kerning less noticeable. I suspect changing the font setting in System Settings triggers a redraw which renders text on a different code path, which is why the issue disappears if you change the font in System Settings, then change it back to the original.
Here's the old Qt4 bug: https://bugreports.qt.io/browse/QTBUG-27257
(In reply to Jens Reuterberg from comment #35) > I don't understand why we would or why that would be visible only in a few > fonts. > > Not saying its impossible but it feels like a fault that is only fixable by > the font designer or the version of the font you downloaded. If not this > would be rather easily spotted in ALL fonts No, it affects all fonts it's just visible with some and is most visible with certain font rendering settings. It should be fixed because it really is a bug and whether it's QML or something, it is related to Plasma. If I switch to XFCE I will never see bad kerning anywhere. It's definitely not the fault of the typeface designer. The other clue that it's a Plasma related issue is how the changing of fonts actually fixes it until next reboot. This shows that that there really is a kerning bug and that it's Plasma related.
To sum everything up, all of the evidence so far points to these few conclusions: - there is a kerning issue *within* Plasma - nothing alike this can be found in other DE: https://imgur.com/a/mPbdV (I just logged into XFCE again and it has perfect kerning everywhere) - the issue seems most prominent when using no hinting _ the issue is more prominent with some fonts (Cantarell, Cabin, Lato) and less with other fonts (Noto Sans, Ubuntu) - OTF vs TTF doesn't matter _ it manifests itself in QML software (panel and widgets) and in kwin when using the Adapta window decoration and when resizing the window - the temporary fix of changing the font to something else and then back is very indicative of confirming the scope of the issue and the cause I guarantee you that you can confirm all this if you try it yourself.
Does this manifest *only* when using Adapta, even if everything else is set up as you indicate (e.g. when using the Cantarell font with no hinting)?
(In reply to Nate Graham from comment #41) > Does this manifest *only* when using Adapta, even if everything else is set > up as you indicate (e.g. when using the Cantarell font with no hinting)? No, when using the Adapta window decoration you have all the regular kerning issues PLUS now kwin(=titlebars) gets messed up as well if you resize the window. The widgets have bad kerning regardless of the desktop or QT theme used. I precisely tried to rule out many other possible factors by making a clean install of KDE Neon in a VM. The spacing is still bad.
(In reply to Nate Graham from comment #41) > Does this manifest *only* when using Adapta, even if everything else is set > up as you indicate (e.g. when using the Cantarell font with no hinting)? It appears in Plasma shell even if Breeze is used as the windeco. It appears in the windeco with any Aurorae theme. Aurorae uses the Plasma library to draw the decoration. In plasma shell, it even appears in widget configuration dialogs.
I want to try to reproduce this. I'll try later tonight.
Investigation with source references: - The Plasma text components have no explicit code to position individual glyphs; the complete 'text' string is used in the QtQuick.Text elements which QtQuick renders [1]. - Aurorae does not use Plasma components for the caption; it uses QtQuick Text elements directly [2]. Given the above investigations, if QtQuick text is rendered wrong, it is an upstream bug, either in QtQuick, or even deeper in the stack (fontconfig, freetype, or even OpenGL drivers). Additional remarks: - If changing fonts forth and back makes a difference, it could also be related to bugs in fontconfig caching. We had related bugs, especially with programs that are started very early, since the fontconfig caches were introduced. - If you use an 'xsettings' daemons, the font properties might additionally get treatment during the startup procedure. Applications that are started before the daemon runs might behave differently than applications that are started after. - Regarding the issue that we had with Qt4 and the native X11 backend vs. the raster backend: That was a limitation of the X11 libraries, not able to position glyphs on subpixel position, but the placement and kerning was changed in Qt4 raster backend to support those. As indicated above, X11 libraries are no longer used to render text. - QtQuick has two text modes: one that uses the same rasterization that is also used for QWidget, the other that uses special OpenGL calls. It is possible that QtQuick when using OpenGL texts could have similar restrictions as with X11 libraries regarding subpixel placement, but you would have to ask QtQuick developers if this is indeed the case. Plasma labels always force the 'desktop' type rendering (QWidget-compatible), unless it is a 'mobile' (phone) platform. [1] https://cgit.kde.org/plasma-framework.git/tree/src/declarativeimports/plasmacomponents/qml/Label.qml#n32 [2] https://cgit.kde.org/kwin.git/tree/plugins/kdecorations/aurorae/src/qml/aurorae.qml#n156
Created attachment 108399 [details] Test QML file I've modified the config dialog qml file for the task manager to remove all Plasma components, and I still see the bug. Can the others that see this bug please confirm if it appears with this QML file (run it with qmlscene)?
(In reply to beojan from comment #46) > Created attachment 108399 [details] > Test QML file > > I've modified the config dialog qml file for the task manager to remove all > Plasma components, and I still see the bug. > > Can the others that see this bug please confirm if it appears with this QML > file (run it with qmlscene)? where do you see it? i see it in the titlebar but only with aurora (and cfeck mentioned it uses qtquick directly so that might not be useful)
I see it in the spacing in the labels for "Sorting: " and "Grouping: ". I commented out the Plasma core library in that file, so it does indeed show this is a Qt bug.
As you're testing stuff, can you confirm if it's an issue with both rendering types or just one. http://doc.qt.io/qt-5/qml-qtquick-text.html#renderType-prop
Ha, with both actually, yeah, although it's a bit worse with NativeRendering.
Created attachment 108409 [details] QML kerning with the QtRendering option Kerning is bad, see too big of a gap between "o" and "u" in "Grouping"
Created attachment 108410 [details] QML kerning with the NativeRendering option Kerning is bad here as well, but this time the word "Sorting" is also affected.
(In reply to Filip from comment #50) > Ha, with both actually, yeah, although it's a bit worse with NativeRendering. I take it you tried the QML file I posted? If so, could you comment on the Qt bug, since they are clearly the ones who have to fix this.
Yes, I tested it using your file. I will register there now and try to do my best to briefly explain everything we've discovered here. Many thanks to the devs, and beojan and rooty as well!
Update: The bug probably only manifests itself with NativeRendering, I didn't add the code all the way.
Is there any way we could switch Plasma to use QtRendering instead of NativeRendering?
To reiterate, this *is* a Qt bug, but it probably won't be fixed soon. Unless there's a reason for using NativeRendering in Plasma, simply switching to QtRendering would fix the issue for Plasma.
Sorry, i did not understood. Is this bug *fixed* upstream, or are we waiting for upstream to fix it? My kerning is still bad in plasmashell.
(In reply to Antonio Orefice from comment #58) > Sorry, i did not understood. > Is this bug *fixed* upstream, or are we waiting for upstream to fix it? > My kerning is still bad in plasmashell. Either one; it doesn't matter from the perspective of this bug. As you can see the upstream bug (https://bugreports.qt.io/browse/QTBUG-49646) is still open. The there are two avenues of attack: 1. Fix the upstream bug and get the kerning for both rendering types improved 2. Universally switch to the QtRendering style throughout plasmashell until #1 is completed (I doubt this would be done since as described above, the issue may be a bit better with QtRendering, but it's not actually resolved)
I think what happened was I made a mistake when testing both modes and misreported that it happens with QtRendering as well. Either way it would be more logical to solve it upstream.
Created attachment 112227 [details] attachment-10430-0.html It actually seems fixed (or a lot better, at least) with QQC2. On Wed, Apr 25, 2018, 04:05 Filip <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=355935 > > --- Comment #60 from Filip <tyx027@gmail.com> --- > I think what happened was I made a mistake when testing both modes and > misreported that it happens with QtRendering as well. Either way it would > be > more logical to solve it upstream. > > -- > You are receiving this mail because: > You reported the bug.
At least for folderviews, i noticed that it happens only when the text is "center aligned" (task manager looks good), so here comes my hacky workaround for plasmashell. in /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml: Find: width: Math.min(label.implicitWidth + units.smallSpacing, parent.width - units.smallSpacing * 4) Replace with: width: Math.min(label.implicitWidth + 4, parent.width - 4) ...restart plasmashell, looks nice to me. (maybe change 4 to something that fits better for your resolution).
I noticed another interesting behaviour. When kerning looks bad, if i open font configuration and change anything related to the font used for the desktop (General font), it looks nice. I mean, not only changing font family and back, but even font size, or "effects", like strikeout or underline. Don't know if it helps anyhow.
Created attachment 112251 [details] attachment-4775-0.html I noticed that years ago. It seems to be because it forces a redraw and apparently follows a different code path. On Thu, Apr 26, 2018, 11:01 Antonio Orefice <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=355935 > > --- Comment #63 from Antonio Orefice <kokoko3k@gmail.com> --- > I noticed another interesting behaviour. > When kerning looks bad, if i open font configuration and change anything > related to the font used for the desktop (General font), it looks nice. > I mean, not only changing font family and back, but even font size, or > "effects", like strikeout or underline. > Don't know if it helps anyhow. > > -- > You are receiving this mail because: > You reported the bug.
*** Bug 396885 has been marked as a duplicate of this bug. ***
Setting: font.hintingPreference: "PreferFullHinting" just before: font.italic: model.isLink in: /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml Fixes bad kerning for me (at the price of having full hinted font).
(In reply to Antonio Orefice from comment #66) > Setting: > font.hintingPreference: "PreferFullHinting" > just before: > font.italic: model.isLink > in: > /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/ > FolderItemDelegate.qml > Fixes bad kerning for me (at the price of having full hinted font). Provided it doesn't result in ugliness, it's better to do: renderType: Text.QtRendering
Imho qt rendering is uglier than full hinting :/