Bug 376094

Summary: Syntax highlighting in Kate 17.12.3 does not use bold and italic
Product: [Applications] kate Reporter: pgkos.bugzilla
Component: syntaxAssignee: KWrite Developers <kwrite-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: bugs.kde.org, kare.sars, mattsch
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description pgkos.bugzilla 2017-02-06 09:40:51 UTC
Steps to reproduce:

1. Open any source code file with bold elements (e.g. keywords).
2. Go to Options -> Kate settings -> Fonts and colors -> Font
3. Change the font (e.g. to Liberation Mono Regular) or just change the size of the font.
4. Apply the font. All bold and italic elements are now displayed with regular font weight.

Kate 16.12.1, KDE Plasma 5.9, Arch Linux 64-bit kernel 4.9.6
Comment 1 Kåre Särs 2017-02-06 14:23:28 UTC
The problem here is that the font does not support bold in all sizes. I for example only get bold with Liberation Mono in sizes 11 and up, but with DejaVu Sans Mono I get bold already at size 10. Some fonts don't even have bold with the mono variant.
Comment 2 pgkos.bugzilla 2017-02-06 18:48:30 UTC
I think it is in fact a Kate bug. If I edit ~/.config/kateschemarc:

[Normal]
Font=Liberation Mono,9,-1,5,50,0,0,0,0,0,Regular
dummy=prevent-empty-group

to

[Normal]
Font=Liberation Mono,9,-1,5,50,0,0,0,0,0,
dummy=prevent-empty-group

then bold and italic elements are again displayed correctly at all font sizes. Seems like "Regular" forces Kate to display everything in regular weight.
Comment 3 Kåre Särs 2017-02-07 10:42:15 UTC
I could not get it to show bold by removing "Regular" at the end of the line...
Comment 4 Dominik Haumann 2017-02-18 11:58:50 UTC
This indeed is rather a font issue. We don't do any magic with the font. If the font doesn't give us "bold" even though we request it, then we cannot do anything about it.

Do you have this issue with all fonts? Or do you have this issue with the same font also in other KDE or Qt applications? Can you reproduce this in Qt Creator? Please try this.

For now, I will close this issue since without further infos we have not really a concrete clue what to do or whether there really is an issue in Kate.

Please report back here for the results with Qt Creator, though. Thanks!
Comment 5 pgkos.bugzilla 2017-02-21 14:34:45 UTC
(In reply to Dominik Haumann from comment #4)
> This indeed is rather a font issue. We don't do any magic with the font. If
> the font doesn't give us "bold" even though we request it, then we cannot do
> anything about it.
> 
> Do you have this issue with all fonts? Or do you have this issue with the
> same font also in other KDE or Qt applications? Can you reproduce this in Qt
> Creator? Please try this.
> 
> For now, I will close this issue since without further infos we have not
> really a concrete clue what to do or whether there really is an issue in
> Kate.
> 
> Please report back here for the results with Qt Creator, though. Thanks!

Yes, I have this issue with all fonts in Kate.

I have tested Qt Creator - no problems there. All monospaced fonts (including Liberation Mono) work at all sizes, keywords can be made bold.

As I have written before, removing trailing "Regular" from kateschemarc fixes the problem.
Comment 6 Erik Quaeghebeur 2018-01-24 12:22:23 UTC
I have a similar issue, bold does not work, but italic does. It appeared not too long ago. (I had a recent upgrade of Plasma to 5.11. Frameworks are at 5.40. Applications are at 17.08.) If I choose a proportional (non-monospace) font like Noto Sans, bold does work.

My kateschemarc does not contain the trailing ‘Regular’ in the normal section.

Let me know if this is clearly a different issue and I should file a separate bug.
Comment 7 Matthew Schultz 2018-03-27 15:46:06 UTC
Any time you change the font to a mono font, the bold and italics stops working.  If I remove ,Regular where font= is specified in kateschemarc, then the problem goes away.  This is still a bug in kate 17.12.3
Comment 8 Christoph Feck 2018-03-27 20:38:46 UTC

*** This bug has been marked as a duplicate of bug 378523 ***