Bug 1149041 - Fontconfig is not applied to all of KDE interface.
Fontconfig is not applied to all of KDE interface.
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Applications
Current
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-Mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-31 02:23 UTC by Marek Paśnikowski
Modified: 2019-09-13 08:21 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
fabian: needinfo? (mail)


Attachments
screenshot showing the problem (396.30 KB, image/png)
2019-08-31 02:30 UTC, Marek Paśnikowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Paśnikowski 2019-08-31 02:23:02 UTC
I wish to have all of the fonts aliased and unhinted. That's correct - I prefer this the most.

Unfortunately, I am no longer able to achieve this result with KDE. All KDE applications like the settings or Kmail antialias the interface strings, while fonts in Plasma, KWin and QtWebEngine are correctly left unprocessed.

I tried many ways of setting up the fontconfig configuration, but all of them failed to be applied.
Comment 1 Marek Paśnikowski 2019-08-31 02:30:19 UTC
Created attachment 816488 [details]
screenshot showing the problem

Take a look at tab and navigations bars. The fonts there are different from the desired settings.
Comment 2 Marek Paśnikowski 2019-09-12 19:02:23 UTC
My apologies. The issue I encountered is most likely unrelated to KDE.

When I had my main laptop fixed, I used a replacement one with the "Transactional Update" installation on it. Now, when I got my laptop back and installed a fresh Tumbleweed on it, it became clear to me that the "Transactional" system is much more user-unfriendly than I anticipated.

In conclusion - whatever I had done with user-level fontconfig, it was ignored in favour of the system-level configuration. And the system-level configuration was set in stone by the very nature of the "Transactional" system.

There is only one thing I don't quite like in the whole situation. My expectation is that changing the font rendering in the KDE's System Settings would apply to everything, regardless of the system defaults.
Comment 3 Wolfgang Bauer 2019-09-12 19:19:29 UTC
Ok, thanks for the additional information.

I don't really see what can be done here from the KDE side though, and I don't know really who maintains the "Transactional" system, there is no Component either.

@Fabian: any idea?
Comment 4 Marek Paśnikowski 2019-09-13 07:47:22 UTC
Sorry for yet again changing my observation. This time I have properly reproduced the bug. The previous experience was related to me NOT logging out after setting up the display scaling of 1.4 . This morning, when I fired up the system, I got greeted by the antialiased fonts.

I tried out many variations of settings in YAST Fonts KDE System Settings and realised that the display scaler either literally resizes everything, including already rendered fonts, or simply ignores fontconfig. On top of that, this behaviour suggests that the display scaling is not applied to ALL of interfaces the same way, because some fonts do remain nicely aliased.

HOWTO reproduce:
1. With display scaling set to 1, disable antialising completely. Re-login.
2. Set display scaling to a higher number (I always used 1.4). Observe that the "enforce DPI" setting in KDE Fonts Settings is also changed to reflect the scaling factor. Re-login.
3. Now the fonts in some KDE interfaces are no longer aliased.

BUG encountered on:
1. Laptop with both integrated and discrete AMD GPUs.
2. Laptop with integrated Intel and discrete NVidia GPUs.
Comment 5 Fabian Vogt 2019-09-13 08:10:11 UTC
I don't think this is related to transactional-update (whether read-only or not) at all. (The right component would be "Kubic", btw).

It is expected that changes to font configuration only take effect after restarting applications, which usually means that logging out and in again is required to have the full effect. For scale factor changes this is even more important because it changes two separate variables and one of them is applied immediately (Xft.dpi) and the other ($QT_SCREEN_SCALE_FACTORS) only after logout.

It this with X11 or Wayland? With X11, the antialiasing settings are usually set using Xresources such as Xft.antialias, otherwise only .config/fontconfig/fonts.conf is read.

Please attach ~/.config/fontconfig/fonts.conf and provide the output of "xrdb -query | grep ^Xft".
Comment 6 Marek Paśnikowski 2019-09-13 08:21:36 UTC
The user's fonts.conf file is unrelated. During today's testing I deleted it but the bug persisted without regard for existence of this file.

As I said - it was my fault. I forgot to re-login after changing the scale factor. I am still on X11.

In short, as long as I don't scale up, I get the expected rendering.