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!