| Summary: | Clipped text in sidebar view with certain non-standard font sizes | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | isalliswell <rahul.vit2014> |
| Component: | sidebarview | Assignee: | Marco Martin <notmart> |
| Status: | VERIFIED FIXED | ||
| Severity: | minor | CC: | bugseforuns, darkwingbuck13, dominik.schlack, fabian, grouchomarx.fr, jensreu, loveshuffleblues, mcpain, nate, now.im.627, robert.bielski |
| Priority: | VHI | Keywords: | regression |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=395817 https://bugs.kde.org/show_bug.cgi?id=401174 |
||
| Latest Commit: | https://cgit.kde.org/kirigami.git/commit/?id=508236f2df2458c53c07bcb3e83e06a6b5c7d332 | Version Fixed In: | 5.53 |
| Sentry Crash Report: | |||
|
Description
isalliswell
2018-04-16 19:34:04 UTC
Confirmed on Kubuntu 17.10. Cannot reproduce with Neon dev unstable in a VM. Same thing for me, same setup as isalliswell. Have tried swapping around fonts but so far nothing changed when doing that Can confirm this. Antergos on kde-unstable. Although for me, it's fontsize dependend. With Roboto Condensed 11 is clipped, 12 is perfect, 13 clipped, 14 perfect. Excellent information, Dominik--confirmed! Seems quite dependent on hitting the right combination of font and size. Here's the result of some testing on my Kubuntu 17.10 machine: 9pt Noto Sans: clipped 10pt Noto Sans: fine 11pt Noto Sans: fine 12pt Noto Sans: clipped 13pt Noto Sans: fine 14pt Noto Sans: clipped 15pt Noto Sans: fine 9pt Ubuntu: clipped 10pt Ubuntu: fine 11pt Ubuntu: clipped 12pt Ubuntu: clipped 13pt Ubuntu: fine 14pt Ubuntu: fine 15pt Ubuntu: clipped Haven't figured out the the pattern yet... (In reply to Nate Graham from comment #4) > > 9pt Noto Sans: clipped > 10pt Noto Sans: fine > 11pt Noto Sans: fine > 12pt Noto Sans: clipped > 13pt Noto Sans: fine > 14pt Noto Sans: clipped > 15pt Noto Sans: fine > > 9pt Ubuntu: clipped > 10pt Ubuntu: fine > 11pt Ubuntu: clipped > 12pt Ubuntu: clipped > 13pt Ubuntu: fine > 14pt Ubuntu: fine > 15pt Ubuntu: clipped > I'll add what i tested: 9pt Roboto Condensed: clipped 10pt Roboto Condensed: fine 11pt Roboto Condensed: clipped 12pt Roboto Condensed: fine 13pt Roboto Condensed: clipped 14pt Roboto Condensed: fine 15pt Roboto Condensed: clipped 9pt SF Display: clipped 10pt SF Display: clipped 11pt SF Display: clipped 12pt SF Display: fine 13pt SF Display: fine 14pt SF Display: fine 15pt SF Display: clipped As pointed out in the comments,it depends on the font size.So,I am just curious if it is related to "Force a content size into the background style item " update to Kirigami in recent Frameworks update to 5.45. Kirigami Content size update: https://phabricator.kde.org/D11189 (In reply to isalliswell from comment #6) > As pointed out in the comments,it depends on the font size.So,I am just > curious if it is related to "Force a content size into the background style > item > " update to Kirigami in recent Frameworks update to 5.45. > > Kirigami Content size update: https://phabricator.kde.org/D11189 No, this is caused by https://github.com/KDE/qqc2-desktop-style/commit/9a5f7d834f86f57e88c3993fbcf4c17d09a01e10 (In reply to Antonio Rojas from comment #7) > (In reply to isalliswell from comment #6) > > As pointed out in the comments,it depends on the font size.So,I am just > > curious if it is related to "Force a content size into the background style > > item > > " update to Kirigami in recent Frameworks update to 5.45. > > > > Kirigami Content size update: https://phabricator.kde.org/D11189 > > No, this is caused by > https://github.com/KDE/qqc2-desktop-style/commit/ > 9a5f7d834f86f57e88c3993fbcf4c17d09a01e10 Can confirm. :/ Sorry about that. I swear I tested this extensively--including with a non-default font size of Noto Sans 11. Unfortunately, that's not one of the affected font and size combinations, so I missed this. The bug seems to be that this *particular* view has some minor mis-alignment that triggers the clipped text bug when Qt Native text rendering is used. I don't think we should roll back the fix; rather, we need to fix whatever it is in this particular scrollview that's triggering the bug. Workaround: open the following file: - Debian-based distros: /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/Label.qml - Other distros: /usr/lib64/qt5/qml/QtQuick/Controls.2/org.kde.desktop/Label.qml Comment out the line that begins with "renderType:" and add a new line consisting of "renderType: Text.QtRendering" Save the file and re-open System Settings. Should be fixed. This will force Qt Text Rendering, which does not have the issue. It will have the effect of making nearly all text using Qml Label items subtly lighter in color though. (In reply to Nate Graham from comment #8) > (In reply to Antonio Rojas from comment #7) > > (In reply to isalliswell from comment #6) > > > As pointed out in the comments,it depends on the font size.So,I am just > > > curious if it is related to "Force a content size into the background style > > > item > > > " update to Kirigami in recent Frameworks update to 5.45. > > > > > > Kirigami Content size update: https://phabricator.kde.org/D11189 > > > > No, this is caused by > > https://github.com/KDE/qqc2-desktop-style/commit/ > > 9a5f7d834f86f57e88c3993fbcf4c17d09a01e10 > > Can confirm. :/ Sorry about that. I swear I tested this > extensively--including with a non-default font size of Noto Sans 11. > Unfortunately, that's not one of the affected font and size combinations, so > I missed this. > > The bug seems to be that this *particular* view has some minor mis-alignment > that triggers the clipped text bug when Qt Native text rendering is used. I > don't think we should roll back the fix; rather, we need to fix whatever it > is in this particular scrollview that's triggering the bug. > > > Workaround: open the following file: > - Debian-based distros: > /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/Label. > qml > - Other distros: > /usr/lib64/qt5/qml/QtQuick/Controls.2/org.kde.desktop/Label.qml > > Comment out the line that begins with "renderType:" and add a new line > consisting of "renderType: Text.QtRendering" Save the file and re-open > System Settings. Should be fixed. > > This will force Qt Text Rendering, which does not have the issue. It will > have the effect of making nearly all text using Qml Label items subtly > lighter in color though. It seems to fix the issue.In Arch the path of the file is slightly different i.e :/usr/lib64/qt/qml/QtQuick/Controls.2/org.kde.desktop/Label.qml Just curious why this issue is not there in KDE Neon Dev-Unstable even though they are using(presumably) the same configurations ? Thank you! Update: it's reproducible in Neon dev unstable in a VM too, but the sizes may be different (I had to raise it up to 14pt for Noto Sans, which is why I didn't see this in testing). (In reply to Nate Graham from comment #10) > Update: it's reproducible in Neon dev unstable in a VM too, but the sizes > may be different (I had to raise it up to 14pt for Noto Sans, which is why I > didn't see this in testing). Just tested it in live boot and was surprised to see that I can't reproduce it in Neon Dev Unstable(downloaded just now).I tested it from font size 9 to 18 in Noto Sans but there was no sign of clipping.Also,enabling and disabling of hinting has no effect on the results.Please find below the screenshots for the same. Font size 9: https://i.imgur.com/JLNrVBe.png Font size 10: https://i.imgur.com/XKGCesF.png Font size 11: https://i.imgur.com/zdlZEUs.png Font size 12: https://i.imgur.com/FS0vxHW.png Font size 13: https://i.imgur.com/nfqMQkB.png Font size 14: https://i.imgur.com/xOwr3lS.png Font size 15: https://i.imgur.com/NUBZUCR.png Font size 16: https://i.imgur.com/NrZHTv7.png Font size 17: https://i.imgur.com/HJUFuGB.png Font size 18: https://i.imgur.com/uhD98yS.png Other than this, one more thing that I noticed is that the font size doesn't scale equally for all categories for example see snaps of font size 17,you will notice that the font size under "Appearance" category is considerable larger as compared to any other category. Hope this helps. Thanks. Same problem here on Arch Linux with the latest packages as of June 2. KDE 5.12.5 Frameworkds 5.46 Apps 18.04.1 I'm hoping this issue is still relevant to the developers with 5.13 coming out soon (it's one of those subtle but frustrating details). Same problem here on Manjaro with KDE 5.12 *** This bug has been marked as a duplicate of bug 395556 *** *** Bug 395556 has been marked as a duplicate of this bug. *** *** Bug 395822 has been marked as a duplicate of this bug. *** I wonder if we should just unconditionally move back to Text.NativeRendering once Plasma can depend on Qt 5.11, which has David's HiDPI fix (i.e. whether at that time we should simply revert https://cgit.kde.org/plasma-framework.git/commit/?id=a21bc11fe11651f6d211489ebfc8435cef877194 and https://cgit.kde.org/plasma-framework.git/commit/?id=3a66e9a0a5ea8dc792d4a2bafbfce3c81b73ebed) Nope, can't do that since the bug with Qt.NativeRendering (https://bugreports.qt.io/browse/QTBUG-67007) is not only not fixed in Qt 5.11, but it's even worse! :( Just tried the latest Developer edition Git-unstable of KDE Neon and the clipping was not there as we are already using "renderType: Text.QtRendering" to bypass the bug. Anyway I noticed a small UI paper cut(not sure) in the settings see the below image: https://imgur.com/a/wAo8f1z Don't you think,it would be better if the highlighted area(bluish) of the selected category not go under/beyond the scrollbar ? (In reply to isalliswell from comment #18) > Don't you think,it would be better if the highlighted area(bluish) of the > selected category not go under/beyond the scrollbar ? We are discussing how to handle scrollbar styles here: https://phabricator.kde.org/T9126 Also, please try not to report new issues in an existing bug report. See https://community.kde.org/Get_Involved/Bug_Reporting#One_issue_per_bug_report (In reply to Antonio Rojas from comment #7) > (In reply to isalliswell from comment #6) > > As pointed out in the comments,it depends on the font size.So,I am just > > curious if it is related to "Force a content size into the background style > > item > > " update to Kirigami in recent Frameworks update to 5.45. > > > > Kirigami Content size update: https://phabricator.kde.org/D11189 > > No, this is caused by > https://github.com/KDE/qqc2-desktop-style/commit/ > 9a5f7d834f86f57e88c3993fbcf4c17d09a01e10 I can confirm that fonts are not clipped anymore once I reverted this patch *** Bug 399254 has been marked as a duplicate of this bug. *** *** Bug 400000 has been marked as a duplicate of this bug. *** *** Bug 401174 has been marked as a duplicate of this bug. *** Here's a patch that fixes this: https://phabricator.kde.org/D17143 This was fixed in a better way with a Kirigami patch, so all users benefited: https://cgit.kde.org/kirigami.git/commit/?id=508236f2df2458c53c07bcb3e83e06a6b5c7d332 Verified that your fix fixes it. Thanks so much, Marco! |
