Bug 384445 - "Draw intense colours in bold" is checked but coloured fonts are not rendering in bold
Summary: "Draw intense colours in bold" is checked but coloured fonts are not renderin...
Status: RESOLVED DUPLICATE of bug 378523
Alias: None
Product: konsole
Classification: Applications
Component: font (show other bugs)
Version: 17.08.0
Platform: openSUSE Linux
: NOR minor
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-06 19:22 UTC by Aayush Agarwal
Modified: 2018-01-28 19:51 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aayush Agarwal 2017-09-06 19:22:36 UTC
My prompt in zsh, which is customized to print in true colours and in bold stopped rendering in bold a couple of days ago. This might be related to a recent bug in tumbleweed:

https://bugzilla.opensuse.org/show_bug.cgi?id=1054448

Both happened at the same time for me or at least if they happened independently I saw them at the same time. I was able to work around the ncurses rendering problem by manually setting term = xterm-color or xterm = linux posted in the bug report, but in ncmpcpp using linux doesn't but that didn't fix the problem regarding bold fonts rendering.

konsole's environment settings:

TERM=xterm-color # term = linux also works but then exiting ncmpcpp doesn't clear the screen
COLORTERM=truecolor


The prompt in question:

# tc = true colour
# mn = machine name
# This is to clean up the code written in the prompt
tcfg="^[[38;2;"
mn_fg="%{$tcfg%}240;224;208m"
tcusr="%{$tcfg%}37;58;199m"
tcpwd="%{$tcfg%}57;187;199m"
# white colour
whtfg="%{$tcfg%}255;255;255m"

# prompt, colours are copied from above
PROMPT="%B%{$tcusr%}%n%{$whtfg%}@%{$mn_fg%}%M%{$whtfg%}:%{$tcpwd%}%~%{$whtfg%}>%b "

Maybe it's my fault, and I'd really like to know how to fix it.
Comment 1 Aayush Agarwal 2017-09-06 19:24:24 UTC
I accidentally forgot to mention: I use source code pro, but I have also tried noto mono and the result is the same.
Comment 2 Christoph Feck 2017-09-06 21:23:17 UTC
Could you please check if ~/.local/share/konsole/*.profile has a Font specifier in the [Appearance] section that ends in the style name (usually Normal or Regular), and just removing it fixes the issue?

See also bug 378523.
Comment 3 Aayush Agarwal 2017-09-07 03:28:22 UTC
I have checked that file and it contained this:

[Appearance]
AntiAliasFonts=true
BoldIntense=true
ColorScheme=Linux
Font=Source Code Pro,9,-1,5,50,0,0,0,0,0,Regular
UseFontLineChararacters=true

[General]
Environment=TERM=xterm-color,COLORTERM=truecolor
Name=Profile 1
Parent=FALLBACK/

Neither removing the entire line nor removing just "regular" over there fixed things for me.

Also I took a look at bug 378523, and fired up Kate to check if it was an issue limited to konsole.

Apparently I'm also having this problem in Kate. I'm interested in editing the kdeglobals file but I'm not sure which lines I'll have to remove. grep'ing for fonts gave me these two lines.

$ cat .config/kdeglobals | grep font
update_info=fonts_global.upd:Fonts_Global
font=Noto Sans,10,-1,5,50,0,0,0,0,0,Regular
Comment 4 Christoph Feck 2017-09-27 14:20:08 UTC
Did you restart Konsole after removing the ",Regular" suffix from the profile font entry? Kate uses its own profiles, so removing them in kdeglobals would not resolve the Kate issue.
Comment 5 Aayush Agarwal 2017-09-27 14:40:05 UTC
I did, and that definitely did not fix the problem.
Comment 6 Aayush Agarwal 2017-09-27 14:50:11 UTC
Also, it seems the problem is limited to monospace fonts. I tried using Noto Sans (variable width) to see what will happen and found that they are working as expected. They are weighted bold when they should be.

This applies to both Kate and Konsole - they are both showing the same results.
Comment 7 Nate Graham 2017-11-17 22:38:18 UTC
Removing ",Regular" from only the Konsole profile files isn't enough; you also have to remove every occurrence from ~/.config/kdeglobals, too.

*** This bug has been marked as a duplicate of bug 378523 ***
Comment 8 Christoph Feck 2018-01-28 14:51:04 UTC
Could you please check if removing style names ("Normal", "Regular", or whatever) from all font configuration entries indeed works? If not, this tickets needs to be deduplicated.
Comment 9 Aayush Agarwal 2018-01-28 19:51:29 UTC
The problem had been solved for me by removing the entries from kdeglobals like Nate had suggested.