Bug 378523 - Regular/Normal Fonts are saved with the styleName string appended to the config entry, preventing e.g. setBold(true) from working correctly
Summary: Regular/Normal Fonts are saved with the styleName string appended to the conf...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kconfig
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: VHI major
Target Milestone: ---
Assignee: Matthew Dawson
URL: https://github.com/qt/qtbase/commit/5...
Keywords: usability
: 343539 376094 376630 383665 384445 385911 387043 387401 387467 390629 391445 392379 393751 395931 408978 416393 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-04-07 02:45 UTC by Mike Lui
Modified: 2020-10-01 19:36 UTC (History)
49 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.68
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Lui 2017-04-07 02:45:01 UTC
font: Hack
all 3 bold, italic, and normal variants exist in /usr/share/fonts/TTF, and fc-match correctly shows them all.

Environment: I select "Draw intense colors in bold font", and select Hack Regular

Expected Behavior:
$ echo -e "\033[1mThis is a BOLD line\033[0m"
will display in bold

Actual Behavior:
text changes color, but is not in bold.

This is separate from this issue: https://bbs.archlinux.org/viewtopic.php?id=192853
as I've exited and restarted konsole.

If I choose the bold variant of the font, the style gets set correctly and there no problems.

I toyed around with the source, and fixed my issue by adding:
if(font.bold())
  font.setStyleName("Bold");
to this block: https://github.com/KDE/konsole/blob/Applications/17.04/src/TerminalDisplay.cpp#L826

However, I'm not sure if that is a valid fix. When I print out the weight and bold values there, they are set correctly, so might also be a Qt issue with font matching.
Comment 1 Mike Lui 2017-04-07 02:58:47 UTC
Reproduced with LiberationMono and Nimbus Mono

Interesting, this does not affect DejaVu Sans Mono.

This is related to but not exactly https://bugs.kde.org/show_bug.cgi?id=343539.
Comment 2 Mike Lui 2017-04-09 14:43:51 UTC
This ended up being an issue with settings in .config/kdeglobalsrc.

I deleted all the font settings there and this fixed the issue.

See:

https://forum.qt.io/topic/78036/bold-fonts-not-working-for-many-fixed-width-fonts-in-linux
Comment 3 Christoph Feck 2017-06-14 00:12:23 UTC
I analyzed the issue and came to the conclusion that it is a bug in KFontRequester not correctly handling the font matching since Qt 5.8.0.

The issue is that KFontRequester tries to find the selected font (or the nearest matching font) in the QFontDatabase. If it finds it there, it actually updates the selected font to what it found there.

For example, if you had selected "Noto Sans", it will scan the database including selected weight and style attributes, and find "Noto Sans Regular" as the best match. Once this match is saved, however, the attributes implied by the font face name takes precedence over the attributes specified by the application.
Comment 4 Christoph Feck 2017-08-30 20:48:11 UTC
*** Bug 383665 has been marked as a duplicate of this bug. ***
Comment 5 Mike Lui 2017-10-20 14:20:58 UTC
With the latest ArchLinux packages: Konsole no longer shows any bold font, regardless of whether the style (regular) is set in the profile or not
This may be konsole specific, as kate does not have this problem

All fonts in the following files have no style (regular, bold, italic, et al) saved with them:
~/.local/share/konsole/Default.profile (in use)
~/.config/konsolerc
~/.config/kdeglobals
~/.kde4/share/config/kdeglobals

Tested with a new KDE user profile, as well.

plasma-framework 5.39.0
qt5-base 5.9.2
konsole 17.08.2
Comment 6 Christoph Feck 2017-10-23 11:29:21 UTC
*** Bug 376630 has been marked as a duplicate of this bug. ***
Comment 7 Jack Kiefer 2017-11-01 22:56:46 UTC
Slightly different hack to get this fixed for Konsole 17.08. I was able to modify the same code block (https://github.com/KDE/konsole/blob/Applications/17.08/src/TerminalDisplay.cpp#L826):

    if (font.bold() != useBold
            || font.underline() != useUnderline
            || font.italic() != useItalic
            || font.strikeOut() != useStrikeOut
            || font.overline() != useOverline) {
        font.setBold(useBold);
        font.setUnderline(useUnderline);
        font.setItalic(useItalic);
        font.setStrikeOut(useStrikeOut);
        font.setOverline(useOverline);
        if (font.bold())
        {
          font.setStyleName(QStringLiteral("Bold"));
        }
        painter.setFont(font);
     }


I was having access issues with the QString constructor, but calling instead calling QStringLiteral was a success (and more efficient, I hear).
Comment 8 Nate Graham 2017-11-01 23:22:41 UTC
Would you be able to submit that as a patch on https://phabricator.kde.org/?
Comment 9 Jack Kiefer 2017-11-02 00:05:47 UTC
Sure thing. Submitted here: https://phabricator.kde.org/D8610
Comment 10 Nate Graham 2017-11-17 21:49:40 UTC
*** Bug 387043 has been marked as a duplicate of this bug. ***
Comment 11 Nate Graham 2017-11-17 22:19:51 UTC
*** Bug 343539 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2017-11-17 22:38:18 UTC
*** Bug 384445 has been marked as a duplicate of this bug. ***
Comment 13 Nate Graham 2017-11-17 22:39:00 UTC
Workaround: remove every occurrence of ",Regular" from the following files:

~/.local/share/konsole/*.profile
~/.config/kdeglobals

You have to do kdeglobals too, not just your Konsole profile files.
Comment 14 Jack Kiefer 2017-11-17 22:57:23 UTC
(In reply to Nate Graham from comment #13)
> Workaround: remove every occurrence of ",Regular" from the following files:
> 
> ~/.local/share/konsole/*.profile
> ~/.config/kdeglobals
> 
> You have to do kdeglobals too, not just your Konsole profile files.

Unfortunately, this workaround did not actually end up working for me. I can't tell for sure, but it seems to me that Konsole tends to ignore the changes in the files and sometimes even overwrite them. The only fix that's worked for me so far is the patch above.
Comment 15 Nate Graham 2017-11-17 22:58:42 UTC
So the problem persists even if none of those files have any occurrences of ",Regular" in them? Or something re-adds ",Regular" to those files?
Comment 16 Jack Kiefer 2017-11-17 23:01:09 UTC
(In reply to Nate Graham from comment #15)
> So the problem persists even if none of those files have any occurrences of
> ",Regular" in them? Or something re-adds ",Regular" to those files?

That is correct. I believe it might re-add the ",Regular" in my attempts to fiddle with the font settings, but the problem definitely persists if none of the files have any occurrences of ",Regular"

For reference, I'm running KDE neon 5.11.3 with Qt version 5.9.1
Comment 17 Mike Lui 2017-11-18 00:28:01 UTC
(In reply to Nate Graham from comment #15)
> So the problem persists even if none of those files have any occurrences of
> ",Regular" in them? Or something re-adds ",Regular" to those files?

See my Comment 5. 
I also noticed the workaround stopped working for me in the reported versions.
I haven't pinpointed at which version the workaround stopped working for me.
Comment 18 Mike Lui 2017-11-18 00:30:22 UTC
(In reply to Mike Lui from comment #17)
> (In reply to Nate Graham from comment #15)
> > So the problem persists even if none of those files have any occurrences of
> > ",Regular" in them? Or something re-adds ",Regular" to those files?
> 
> See my Comment 5. 
> I also noticed the workaround stopped working for me in the reported
> versions.
> I haven't pinpointed at which version the workaround stopped working for me.

To clarify, I'm not seeing ",Regular" re-added.
The non-bold bug in Konsole now appears to be independent of ",Regular" appearing in the listed files.
Comment 19 Nate Graham 2017-11-18 02:30:34 UTC
Hmm, that's strange--I can perfectly reproduce the issue as well as the workaround in KDE Neon dev unstable.

Regardless, after digging into the code, I'm starting to wonder whether or not this really is an issue in KFontRequester. It seems that the cause was a change to QFont in Qt (https://github.com/qt/qtbase/commit/5dd907bf639f43be7f2cdfdd44ec3795f1b31bf6) that added font style information. That seems like an important and useful change--we *should* save font style information! Only in a few situations should that be overridden. So I'm leaning towards fixing all affected KDE apps to work with the new QFont save string, because we *should* keep the font style information, but those apps need some new code because previously they didn't have to content with style information being available.

We even already have patches for a couple of affected apps.

Thoughts, Christoph? Or have I misunderstood something?
Comment 20 Martin van Es 2017-11-27 19:14:54 UTC
You're right, it seems related to changes in Qt, I've mentioned the problem upstream and some replies.
https://bugreports.qt.io/browse/QTBUG-63792
Comment 21 Nate Graham 2017-11-28 14:05:10 UTC
*** Bug 387401 has been marked as a duplicate of this bug. ***
Comment 22 Dominik Haumann 2017-11-29 16:40:18 UTC
Imho this is a grave issue. Essentially, it breaks entire Kate, KDevelop, Kile. And possibly any other application the relies on bold font face.

Changing prio to HI.
Comment 23 RJVB 2017-11-30 11:34:56 UTC
Probably a redundant observation, but doing something like

QSettings().setValue("font", font)

instead of

QSettings().setValue("font", font.toString())

saves the font in the legacy way, without the problematic stylename extension. To react to Nate's remark: all required information IS already contained in the fontspec string, esp. weight is represented as a standardised numerical value (e.g. 63 = medium/semibold, regular is 57, bold is 75). Qt does have some remaining issues with the less usual weights (AFAICT) and saving the exact stylename could help. The problem is that this is font-specific: some fonts have Medium where others call that Semibold (in all kinds of spellings) or even demi-bold - which is how other fonts call their actual bold face. So a canonical stylename shouldn't be inherited, should be regenerated on the fly when queried and should be overridden by any of the other methods of changing how a font looks (other than size).

It's of course possible that Qt only have to fix their QFont::setBold() implementation but they will almost certainly not do that in all affected (older) versions.
Comment 24 Nate Graham 2017-11-30 20:48:23 UTC
*** Bug 387467 has been marked as a duplicate of this bug. ***
Comment 25 RJVB 2017-11-30 22:07:21 UTC
>         if (font.bold())
>         {
>           font.setStyleName(QStringLiteral("Bold"));
>         }

What if you do `font.setWeight(QFont::Bold)` instead, possibly overriding the styleName with `font.setStyleName(QString())` (supposing that indeed clears the property)?

The impression I'm getting here is that the styleName property is something that's best left untouched except when you want "to match the font with irregular styles" (citing the 5.8.0 documentation for QFont). That documentation also suggests the properties in question might not be possible to capture with the other QFont attributes but I'd take that with a grain of salt. Qt determines that styleName somehow and presumably that's from metadata stored in the font and relayed through libfreetype of CoreText (styleName is apparently not used on other platforms, yet).
Comment 26 RJVB 2017-12-07 11:11:06 UTC
FYI: I thought it might be good to have a central ticket related to font handling in general, not to specific things like "setBold doesn't work":

https://bugreports.qt.io/browse/QTBUG-65037

It includes a WIP function to strip the style name, but that may have unexpected results due to how QFonts work internally (= return a different font from the same family).

Please don't hesitate to chime in there.

Dominik is right that this is a very annoying issue which potentially far-reaching implications. Styles may also use setBold() to render certain UI elements, and they'll typically do that on the fly. This will either not work anymore or it will become significantly more costly.

Come to think of it: I use a "semibold" generic UI font and have long been noticing (in applications that offer style selection, like the oxygen-demo) that trying Breeze and then switching back to another style leaves the generic font in "Regular" weight. I understand now that Breeze is only partly to blame for this.
Comment 27 Ahmad Samir 2017-12-14 20:08:00 UTC
The Summary of this bug should be changed, I think. This is a QFont issue, now it adds the styleName to the QFont description when using toString().

An observation, the only ",Regular" that seems to matter in kdeglobals is the "font=" entry, the other ones don't affect this bug. This theory is backed by this upstream code review https://codereview.qt-project.org/#/c/181645/ (which was accepted IIUC).
Comment 28 RJVB 2017-12-14 20:47:03 UTC
> This is a QFont issue,

True.

> now it adds the styleName to the QFont description when using toString().

Only when a style name has been set AFAIK.

> An observation, the only ",Regular" that seems to matter in kdeglobals is
> the "font=" entry, the other ones don't affect this bug. This theory is

That's only because the other fonts are rarely if ever set to bold or italic - on your desktop. The widget style you use can also do this kind of thing (we just committed a workaround in QtCurve). And evidently it doesn't matter what style you chose (though the platform integration plugin indeed has a new habit of setting the style name to "regular" regardless of what the user chose.

> https://codereview.qt-project.org/#/c/181645/ (which was accepted IIUC).

Yes, it's in 5.9(.3) but not yet in 5.8.0 . It also doesn't fix the whole issue, it just makes it a bit less "viral".
Comment 29 Nate Graham 2017-12-16 17:01:48 UTC
RJVB, I really appreciate all the work you've done on this multifaceted issue. What's the current status and what's our path forward?
Comment 30 RJVB 2017-12-16 17:44:37 UTC
I think your guess is as good as mine. There appears to be a consensus among the Qt devs that the style name will continue to work as it does currently, despite some disagreement on the details (like whether the font dialog should always set a style name).

Some day there may be API to unset attributes. That's not currently possible, for instance, QFont::setBold(false) will tell the font engine that you want a font that's not bold. That's not necessarily the font you started out with after you called setBold(true).

Until that time we'll need some kind(s) of workaround (like the function to recreate a font without stylename I committed to QtCurve) and KDE code should probably aim to avoid using the style name as far as possible. This would have been easier if there were a KFont class...

It could be very useful to have a more capable (geeky) font explorer that exposes some more of the information that Qt uses internally, like a font's PANOSE data. I keep reading that style names aren't needed for fonts that can be represented in that system, but AFAIK I have only fonts that are in that category (and wouldn't know how to identify a font that isn't). That makes it hard to test the workarounds and to figure out if code can determine reliably when a style name can NOT be avoided.
Comment 31 Nate Graham 2017-12-16 18:23:37 UTC
So should we patch Breeze and Oxygen in the same way? Or is there no real way for us to avoid app-specific patches like https://phabricator.kde.org/D8610?

FWIW I've noticed that as of Plasma 5.11 and Qt 5.9.1, Bold text appears correctly in Dolphin and Gwenview's URL bars.
Comment 32 Christoph Feck 2017-12-16 21:37:13 UTC
A good fix would be in KFontRequester. It should clear the styleName after database lookup, if the same font is found when only using the family, weight and style attributes, possibly by doing two such lookups.

There is no need to workaround it in widget styles or even applications.

Unfortunately I have no development environment right now, but I can review any patches made to KFontRequester::nearestExistingFont().
Comment 33 RJVB 2017-12-16 22:42:17 UTC
(In reply to Christoph Feck from comment #32)
> A good fix would be in KFontRequester.

Indeed, that's one central place where a workaround/fix can be implement. However,

> There is no need to workaround it in widget styles or even applications.

I don't think that can be guaranteed. Applications can use Qt's native font dialog for instance (that might even be the default behaviour when not running under a Plasma setting). And widget styles can be used in "pure Qt" applications.

> Unfortunately I have no development environment right now, but I can review
> any patches made to KFontRequester::nearestExistingFont().

Would the function I added to QtCurve be appropriate?

QFont Style::FontHelper::fontStripStyleName(const QFont &f) const
{
    const QString &styleName = f.styleName();
    if (styleName.isEmpty()) {
        // we can simply return the input font
        return f;
    } else {
        // Check for a mismatch between styleString and styleName; when
        // found the font probably had a style name set directly instead of
        // receiving it e.g. via the FontDialog. This means its attributes
        // may still correspond to the original font, not to the current style.
        // Do a database lookup to get a consistent QFont instance to work with,
        // so that methods like setWeight(), setStyle() will work as expected.
        QFont g = (m_fntDB->styleString(f) != styleName) ?
            m_fntDB->font(f.family(), styleName, f.pointSize())
            : QFont(f.family(), f.pointSize(), f.weight());
        if (auto s = f.pixelSize() > 0) {
            g.setPixelSize(s);
        }
        g.setStyleHint(f.styleHint(), f.styleStrategy());
        g.setStyle(f.style());
        if (f.underline()) {
            g.setUnderline(true);
        }
        if (f.strikeOut()) {
            g.setStrikeOut(true);
        }
        if (f.fixedPitch()) {
            g.setFixedPitch(true);
        }
        return g;
    }
}
Comment 34 Dominik Haumann 2018-01-21 00:00:02 UTC
Any news on this? *gentle ping*
Comment 35 Jack Kiefer 2018-01-21 01:10:31 UTC
(In reply to Dominik Haumann from comment #34)
> Any news on this? *gentle ping*

For real. There's been multiple Konsole updates, but I keep going back to my older hacky patched version...
Comment 36 RJVB 2018-01-21 09:22:19 UTC
I thought a fix existed for the font requester that makes it not set the stylename? That should be all that's needed here.
Comment 37 Erik Quaeghebeur 2018-01-26 10:51:11 UTC
Is there any workaround still available? (Qt 5.7.1, Frameworks 5.40.0, Plasma 5.11.5, Applications 17.08.3)
Comment 38 Maciej Mrozowski 2018-01-26 21:00:29 UTC
As workaround, remove ",Regular" from related config files. Those are, among others:
~/.config/kdeglobals (fallback)
~/.config/kateschemarc (for text editors)
terminal:
~/.config/konsolerc
~/.local/share/konsole/*.profile
You might want to locate config file specific to application you use (in ex. komparerc, etc).
Comment 39 Erik Quaeghebeur 2018-01-26 21:22:46 UTC
(In reply to Maciej Mrozowski from comment #38)
> As workaround, remove ",Regular" from related config files.
There are no ",Regular" strings in there for me, and I still have the problem. That was already noted in comment 16; I should have been explicit about this.
Comment 40 RJVB 2018-01-26 22:05:47 UTC
You could try rebuilding the plasma-integration plugin with this patch applied:
https://phabricator.kde.org/D9070
Comment 41 Fonic 2018-01-27 11:56:22 UTC
(In reply to RJVB from comment #40)
> You could try rebuilding the plasma-integration plugin with this patch
> applied:
> https://phabricator.kde.org/D9070

Tested this on Gentoo Linux amd64, KDE Plasma 5.11.5, KDE Frameworks 5.40.0, Qt 5.7.1 (all current stable as of 01/27/18), seems to have no effect at all, same issues regarding bold/italic in all applications.

I'm suffering from this since upgrading after KDE 5.11.x was stabilized on Gentoo a couple of days ago. Very annoying.

Also, I don't have any ',Regular' strings in any of the configuration files.
Comment 42 Christoph Feck 2018-01-27 13:08:12 UTC
> I don't have any ',Regular' strings in any of the configuration files

Then you are having a different issue. This ticket is about KFontRequester adding those style names whenever a font is selected.
Comment 43 Denis Lisov 2018-01-27 13:15:40 UTC
(In reply to Fonic from comment #41)
> Tested this on Gentoo Linux amd64, KDE Plasma 5.11.5, KDE Frameworks 5.40.0,
> Qt 5.7.1 (all current stable as of 01/27/18), seems to have no effect at
> all, same issues regarding bold/italic in all applications.
> 
> I'm suffering from this since upgrading after KDE 5.11.x was stabilized on
> Gentoo a couple of days ago. Very annoying.
> 
> Also, I don't have any ',Regular' strings in any of the configuration files.

I've seen this issue without ',Regular' too. However, at some moment it transformed into this one (i.e., the ',Regular' parts appeared in files) and after removing them the problem was gone. At the moment bold works correctly for me, but I'm on unstable Gentoo, so KDE 5.11.5, frameworks 5.42.0, Qt 5.9.3.
Comment 44 Denis Lisov 2018-01-27 13:21:54 UTC
(In reply to Denis Lisov from comment #43)
> At the moment bold works correctly
> for me, but I'm on unstable Gentoo, so KDE 5.11.5, frameworks 5.42.0, Qt
> 5.9.3.
(correction: Plasma 5.11.5, frameworks 5.42.0, Qt 5.9.3, apps 17.12.1)
Comment 45 Jack Kiefer 2018-01-27 21:56:12 UTC
Again, folks, please see Mike Lui's comment above:

> The non-bold bug in Konsole now appears to be independent of ",Regular" appearing in the listed files.
Comment 46 nfxjfg 2018-01-27 22:00:16 UTC
When is a bug fix scheduled? This is getting annoying.
Comment 47 Christoph Feck 2018-01-28 02:33:00 UTC
For which bug? If manually removing the style name from config files does not fix the non-bold issue, then you are seeing a different bug, which you might need to report separately.
Comment 48 Mike Lui 2018-01-28 05:03:28 UTC
Is that the right course of action?

The original bug report was that bolded text did not work in Konsole. Many of the bugs marked as duplicates of this bug reported the same thing.

Now there needs to be another bug report for the workaround for the original bug? Shouldn't there be one bug report to enable bold text?
Comment 49 Christoph Feck 2018-01-28 14:20:18 UTC
If this ticket gets fixed by no longer writing the style name to the configuration files, this would not fix your issue. So there really needs to be a separate ticket for that.
Comment 50 Christoph Feck 2018-01-28 15:06:17 UTC
To be more specific, starting with comment #5 we see two different issues discussed, which (according to that comment) is specific to Konsole. I added a comment to bug 384445 asking for clarification.
Comment 51 Erik Quaeghebeur 2018-01-31 20:23:10 UTC
(In reply to Christoph Feck from comment #49)
> If this ticket gets fixed by no longer writing the style name to the
> configuration files, this would not fix your issue. So there really needs to
> be a separate ticket for that.

Perhaps it is Bug 376094, where at least the WAITINGFORINFO should be lifted?
Comment 52 Christoph Feck 2018-01-31 20:26:21 UTC
No, the reporter there stated that removing the style names from the kate config files fixed the issue for him.
Comment 53 Erik Quaeghebeur 2018-01-31 21:46:12 UTC
(In reply to Christoph Feck from comment #52)
> No, the reporter there stated that removing the style names from the kate
> config files fixed the issue for him.

Then that is a resolved duplicate of this?
Comment 54 Erik Quaeghebeur 2018-01-31 22:03:48 UTC
(In reply to Christoph Feck from comment #49)
> If this ticket gets fixed by no longer writing the style name to the
> configuration files, this would not fix your issue. So there really needs to
> be a separate ticket for that.

I've created Bug 389725.
Comment 55 Nate Graham 2018-03-26 21:41:01 UTC
*** Bug 392379 has been marked as a duplicate of this bug. ***
Comment 56 Stefano 2018-03-27 05:19:14 UTC
(In reply to Maciej Mrozowski from comment #38)
> As workaround, remove ",Regular" from related config files. Those are, among
> others:
> ~/.config/kdeglobals (fallback)
> ~/.config/kateschemarc (for text editors)
> terminal:
> ~/.config/konsolerc
> ~/.local/share/konsole/*.profile
> You might want to locate config file specific to application you use (in ex.
> komparerc, etc).

I tried this workaround. It works for kate/kwrite, but not for konsole, which remains without bolds.
Comment 57 Yaroslav Sidlovsky 2018-03-27 09:02:30 UTC
(In reply to Stefano from comment #56)
> (In reply to Maciej Mrozowski from comment #38)
> > As workaround, remove ",Regular" from related config files. Those are, among
> > others:
> > ~/.config/kdeglobals (fallback)
> > ~/.config/kateschemarc (for text editors)
> > terminal:
> > ~/.config/konsolerc
> > ~/.local/share/konsole/*.profile
> > You might want to locate config file specific to application you use (in ex.
> > komparerc, etc).
> 
> I tried this workaround. It works for kate/kwrite, but not for konsole,
> which remains without bolds.

It works for me after I removed _all_ `,Regular` entries from ~/.config/kdeglobals
Comment 58 Stefano 2018-03-27 16:29:21 UTC
(In reply to Yaroslav Sidlovsky from comment #57)
> (In reply to Stefano from comment #56)
> > (In reply to Maciej Mrozowski from comment #38)
> > > As workaround, remove ",Regular" from related config files. Those are, among
> > > [...]
> > I tried this workaround. It works for kate/kwrite, but not for konsole,
> > which remains without bolds.
> 
> It works for me after I removed _all_ `,Regular` entries from
> ~/.config/kdeglobals

You are right. After removing the "Regular" attribute to every font entry including every non-monospace font, now bold works even on konsole.
I guess that touching the font settings would make the issue return.
Comment 59 Christoph Feck 2018-03-27 20:38:46 UTC
*** Bug 376094 has been marked as a duplicate of this bug. ***
Comment 60 Dominik Haumann 2018-04-15 11:53:17 UTC
For Kate, this has just been fixed for KDE Frameworks 5.56: https://phabricator.kde.org/D12221

Baybe other apps can / should have a similar fix. The fix is young, though, and not yet we'll tested.
Comment 61 RJVB 2018-04-15 17:08:25 UTC
On Sunday April 15 2018 11:53:17 Dominik Haumann wrote:

> For Kate, this has just been fixed for KDE Frameworks 5.56:
                                                          ^^

Really? Patience, Watson, Patience! :)
Comment 62 Ahmad Samir 2018-04-30 15:01:04 UTC
*** Bug 391445 has been marked as a duplicate of this bug. ***
Comment 63 Ahmad Samir 2018-04-30 15:02:37 UTC
*** Bug 390629 has been marked as a duplicate of this bug. ***
Comment 64 Christoph Feck 2018-05-02 02:35:25 UTC
*** Bug 393751 has been marked as a duplicate of this bug. ***
Comment 65 Fabian Vogt 2018-06-12 16:45:24 UTC
Git commit 2e971be576d24a82974eaf2397d4703fca0188d8 by Fabian Vogt, on behalf of R.J.V. Bertin.
Committed on 12/06/2018 at 16:45.
Pushed by fvogt into branch 'master'.

KDE platform plugin: don't force default stylename on user-specified fonts

Summary:

Applying the default, hardwired QFont::styleName to one of the standard fonts which then gets changed to a user-selected font can break expectations because of the way Qt handles such canonical stylenames, letting them override the effects of other QFont methods invoked subsequently. It can for instance become impossible to make the font bold afterwards: see https://bugs.kde.org/show_bug.cgi?id=378523, https://bugreports.qt.io/browse/QTBUG-63792 or https://bugs.kde.org/show_bug.cgi?id=387467 .

This may be a Qt "feature" that's here to stay, sadly.

The change proposed here makes it possible (again) for users to prevent font weight rendering regressions by removing the stylename extension from configuration files manually as documented in several locations. This approach is useless when the KDE platform theme plugin then applies the default stylename, an issue that can be avoided by calling QFont::setStyleName() only when no user-specified font is available.

Evidently the manual intervention could be replaced with a change in the way font settings are stored; this would also require the current change.

Test Plan:
Works as intended on Linux. An equivalent modification in my osx-integration fork of the platform theme plugin for Mac has the same effect (without it "Segoe UI Semi-bold" is no longer made bold where it should in dialogs).

I don't think there are possible side-effects:
- a stylename still gets set either if there is no user-selected font or if that selection includes a stylename extension
- font specifications should still contain all the required information they always had; not applying a guessed stylename only means that no conflict can arise with the combined set of numeric style and weight attributes.

Reviewers: #frameworks, davidedmundson, graesslin, cfeck, dfaure

Reviewed By: dfaure

Subscribers: bkchr, ahmadsamir, rdieter, abetts, anthonyfieroni, ngraham, cfeck, fvogt, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D9070

M  +4    -1    src/platformtheme/kfontsettingsdata.cpp

https://commits.kde.org/plasma-integration/2e971be576d24a82974eaf2397d4703fca0188d8
Comment 66 Christoph Feck 2018-10-10 03:27:49 UTC
*** Bug 395931 has been marked as a duplicate of this bug. ***
Comment 67 Ammy 2018-11-07 10:17:12 UTC
The font style "Regular" string is still being added in kdeglobals when selecting a font via System Settings! This is a brand new Plasma install on Arch Linux with qt 5.11.x and Plasma 5.14.3. Removing "Regular" does fix the issue with bold fonts, but isn't the patch above help to not insert font styles anymore?
Comment 68 promask 2019-04-17 17:09:33 UTC
hm///
Comment 69 Eugene 2019-04-18 18:50:23 UTC
This bug is still present in Kubuntu 19.04 beta. So it concerns not only Arch.
Comment 70 Castro B 2019-06-19 09:58:14 UTC
letting them override the effects of other QFont 
methods invoked subsequently.

Castro B,
https://sparpedia.ch
Comment 71 Nate Graham 2019-06-22 09:41:47 UTC
*** Bug 408978 has been marked as a duplicate of this bug. ***
Comment 72 farmboy0 2019-06-26 17:11:38 UTC
I have the same problem with Konsole 18.12.3 with
KDE Frameworks 5.59.0
Qt 5.12.3 (built against 5.12.3)

I use a bold font as default in my Konsole profile.
I can restore the bold font when I edit the profile, set the font back to bold and make another change so the setting think a change actually happened and applying the changes.

After closing and reopening of Konsole the font is reset to Regular again.
Comment 73 Eugene 2019-08-21 20:29:17 UTC
There is no such bug in Kubuntu 19.04:

KDE 5.16.4
KDE Frameworks: 5.61
Qt: 5.12.2


But it still is in Kubuntu 18.04.3:

KDE 5.12.8
KDE Framworks: 5.47
QT 5.9.5

Something should be backported, but I can't understand what is.
Comment 74 Ahmad Samir 2019-10-05 19:35:01 UTC
Konsole issue was fixed by: https://phabricator.kde.org/R319:41693fe9ee263f8f2281852a740ee52d55f003ef

KTextEditor/Kate was fixed by: https://phabricator.kde.org/R39:4d91fa7e918d983e6569798dfe20c7c9faf4bb9e

The fonts KCM has been pored to QML and doesn't use KFontRequester, IIUC. I'll Keep this one open for KFontRequester.

For the QML fonts KCM, see bug 412645.
Comment 75 Nate Graham 2019-10-07 02:20:40 UTC
*** Bug 385911 has been marked as a duplicate of this bug. ***
Comment 76 Nate Graham 2020-01-17 23:22:37 UTC
*** Bug 416393 has been marked as a duplicate of this bug. ***
Comment 77 Ahmad Samir 2020-03-02 10:51:41 UTC
Git commit a2774ff5b41987c3919a9ecc54c70e0d4b3758ae by Ahmad Samir.
Committed on 02/03/2020 at 10:51.
Pushed by ahmadsamir into branch 'master'.

[KConfigGui] Clear styleName font property for Regular font sytles

Summary:
If the styleName property is set for a QFont, using setBold(true) would
lead to Qt using an "emboldended"/synthetic font style instead of using
the bold style provided by the font itself (usually as a standalone font
file), the former looks ugly (IIUC, Freetype emboldens fonts as a last
resort for fonts that don't provide a bold style at all).

Accoring to upstream[1] the styleName property is useful for fonts with
fancy style names, and also it shouldn't be set if it's not needed; and
indeed using styleName with e.g. "Regular" doesn't make sense, as there
is no "Regular Bold" style AFAICS.

Checking for "Regular|Normal|Book|Roman" is based on examining the font
styles provided by the font packages available on OpenSuse Tumbleweed ATM,
(I didn't include some of the weird/non-common ones e.g. I've seen "Roma"
and "Rounded"). Some statistics about the "Regular"-like font styles from
my testing:
Regular:  2486
Normal:  66
Book:  20
Roman:  13

For more details see:
[1] https://bugreports.qt.io/browse/QTBUG-63792
https://bugs.kde.org/show_bug.cgi?id=378523

FIXED-IN: 5.68

Test Plan:
All unit tests still pass.

Changing the fonts via e.g. the fonts KCM doesn't append the font sytleName,
to the relevant font config entry, if the "Regular" style or co. is used.

A simple test, look at the current dir name in the Dolphin url bar with
and without ",Regular" appended to the font= entry (assuming you're using
Noto Sans or DejaVu Sans as the styleName varies from font to font).

Reviewers: #frameworks, dfaure, davidedmundson, cfeck, ervin

Reviewed By: dfaure

Subscribers: kde-frameworks-devel

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D27735

M  +16   -3    src/gui/kconfiggroupgui.cpp

https://commits.kde.org/kconfig/a2774ff5b41987c3919a9ecc54c70e0d4b3758ae
Comment 78 RJVB 2020-09-06 09:15:43 UTC
I should have seen the Phab PR above or at least the previous comment, but somehow didn't.

Why only strip the Regular styleName? The property is redundant at best and I think that the synthetic font argument applies to other styles as well. As an example: I use a Semi-Bold typeface in many cases (including as GUI font) because the corresponding regular is too light. Software emboldening of a semi-bold will )probably) not give an inferior quality bold typeface but something heavier (semi-extra-bold?).

I would argue that code shouldn't have to strip redundant properties but should rather have to make some extra calls in order to obtain them - QFontInfo::styleName() in this case. I know that QFontDialog() will return fonts that have the styleName set ... but the goal of the KFont* APIs is to improve on what Qt has to offer, no?

On a related note: wouldn't it be possible to obtain a QFont that has never had the styleName property set internally, and then add it, rather than depend on being able to strip it?
Comment 79 Ahmad Samir 2020-10-01 19:36:40 UTC
I didn't go for dropping that property unconditionally, because I took the path of least destruction, doing the minimum amount of removal to get setBold(true) to work properly.

IIUC, the styleName property is still useful in some cases https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/b52622993b45a61c4060d19517a5c3b833b3b854
(the Noto font family is one widely-used example of a family with many styles).

And there could be other cases (that I am not aware of) where the styleName property is actually useful 

Also the fonts KCM has switched to using KFontChooserDialog (instead of QFontDialog), the former doesn't return fonts with the styleName set for regular-like font styles.

> On a related note: wouldn't it be possible to obtain a QFont that has never had the styleName property set internally, and then add it, rather than depend on being able to strip it?
That's what the commit from comment#77 is trying to do; if the styleName is never added to the config file when saving the settings, then when loading those settings, the resulting QFont won't have the styleName property set.