Created attachment 40675 [details]
Screenshot showing the bug

Konsole screenshot showing the bug (font is Fixed [misc])

Created attachment 40733 [details]
Konsole showing the cropped fonts problem

This seems to be the case with any bitmap font (Andale mono has the same problem). Attached is a screenshot showing konsole with Andale mono and the 'cropped' dir entry problem.

I can confirm this as well, using fonts Andale Mono, Lucida Console, Inconsolata. The latter two at least are TTF fonts. I didn't notice the problem until after installing the updated kdegraphics package, which installed some new QT packages as dependencies. I read somewhere that Konsole depends on QT for font rendering, so perhaps QT is not supplying a bold font and xterm is falling back to overdrawing the font which produces the same bug. 

Workaround for now is to switch to another font (some of the built-in monospace fonts seem to work better, although technically they suffer the same problem the width differences are less drastic so little to no clipping occurs).

Kate suffers from the same problem so it probably is a Qt bug that surfaces in KDE 4.4.0 (or a coincidence). Nevertheless I'd like to propose to disable bold coloured directory entries in Konsole since they don't add any value, or make it configurable in my profile?

I can confirm it. I also tried a `setterm -bold [on/off]` but it applies to the whole terminal. We should be able to configure fonts for highlighted characters, but there is no way at the moment, as far as I know.

Created attachment 40972 [details]
Cropped fonts screenshot

*** This bug has been confirmed by popular vote. ***

Same here on KDE 4.3.5 after upgrading Qt to 4.6. So it really seems to be Qt related.

Possibly related/regression of bug #87240 ?

I can confirm it happens on one computer, but not on another;

Affected computer:

 with a nVidia card (x86 system), but does not happen on my other computer with an ATI (x86_64 system).

** Ignore previous post **
I can confirm it happens on one computer, but not on another;

Affected computer:
 Linux cubby49 2.6.31-gentoo-r6 #1 SMP Sat Dec 19 09:56:21 EST 2009 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz GenuineIntel GNU/Linux
 nVidia Corporation NV25 [GeForce4 Ti 4200] (rev a3)
 qt-4.6.2
 konsole-4.3.5
 kdelibs-4.3.5
 nvidia-drivers-96.43.16
 (**) NVIDIA(0): DPI set to (96, 96); computed from "DPI" X config option

Unaffected Computer:
 Linux mutley 2.6.31-gentoo-r6 #1 SMP Sat Dec 19 09:47:10 EST 2009 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux
 ATI Technologies Inc RV730XT [Radeon HD 4670]
 qt-4.6.2
 konsole-4.3.5
 kdelibs-4.3.5
 ati-drivers-9.11
 (II) fglrx(0): DPI set to (92, 92)

I can supply any other info on request.

Any movement on this?  It essentially renders konsole and any text-mode apps useless if they use bold.

I can confirm this on my machine. Konsole renders bold text ugly and I am resorting to hacks and settings on various applications to make it usable on konsole. Gnome-terminal on the same system on kde seems to be rendering alright.

This should be a high priority issue as it affects most of us who use Konsole primarily.

This renders konsole sometimes unusable for me, please look into this. I've attached a screenshot.

Created attachment 43171 [details]
Bold fonts blurry and cut off in directory listing

I have the same problem here. Fixed [Misc] font size 8 misrenders, whereas font size 9 does not.

This only appears to happen for synthetically bolded fonts.

That is, fonts that do not ship with a bold version. For example, Inconsolata only ships with a Medium/Roman; there are no bold, italicized, or bold italicized version. While this appear in the font selection dialog, they are rendered dynamically. This implies the problem is lower down in the Qt or Fontconfig/Xft level of the font rendering stack.

I've been trying to turn off fontconfig's synthetic bolding (AFAIK, it's just a file in /etc/fonts/? but apparently not), but haven't been successful.

Samat,

I observed the same and I use Aurulent Sans Mono. I used fontforge to copy the Mono font as a bold font and that works for now.

The problem lies in ANSI escape codes used to switch colors in terminal. They don't distinguish between bold and bright, so it is up to implementation what to do if it sees such a command. In KDE3, Konsole was just making the color intensive. In KDE4, it is making the color intensive and the font bold.

IMHO, this behavior should be user-configurable. I have created a patch which implements the respective per-profile option and posted it to KDE Reviewboard (http://reviewboard.kde.org/r/4201/). Feel free to review, test and comment.

Looks good to me.  Please commit if you have a KDE SVN account.
> I'll do this tomorrow, thanks for reviewing!

Yes, it's finally getting fixed!! Thx for the fix Valentine! :)

(In reply to comment #20)
> Looks good to me.  Please commit if you have a KDE SVN account.
> > I'll do this tomorrow, thanks for reviewing!
> 
> Yes, it's finally getting fixed!! Thx for the fix Valentine! :)

ahem, if I understand it correctly, this is NOT a fix

it is just a workaround not to use bold variant of a font

but the problem, as described within the initial report, is that the display of the bold font is wrong:

"When I select a font that can handle the bold type, the name of the directory is cut-off at the width of the non-bold version (approximately)."

this is exactly what happens to me - if I select Terminus font, that has the bold version of exactly the same width as the non-bold one, the characters are crippled, and the width of the bold text is wider than of the non-bold and it gets cut, while the width *should* be the same

it is like konsole would try to make bold by crippling the normal version, instead of using the real bold variant of the font, see comment #17 (but on my system, it happens for *all* fonts)

I agree that I was a little enthusiastic in my comment, but I'm quite delighted to see that there finally will be a work-around for the ugliness on display.

On a sidenote: I never *ever* missed having the ability to display highlighted characters in konsole as bold (intensive seemed to fit the job perfectly), so the update in KDE 4 may be seen as a regression or at least a needless addition as Valentine states in his code review.

isn't this a dupe of bug #217700?

Did this fix make it into 4.4.5? I can't seem to find it.

(In reply to comment #19)
> The problem lies in ANSI escape codes used to switch colors in terminal. They
> don't distinguish between bold and bright, so it is up to implementation what
> to do if it sees such a command. In KDE3, Konsole was just making the color
> intensive. In KDE4, it is making the color intensive and the font bold.

then isn't this a KDE4 regression?  shouldn't the behavior be reverted to just making the color "intensive"?  i admit that i don't know what you mean by that phrase--do you mean increasing the color saturation?

there really should be a way to make fixed-width fonts bold without making them wider than their non-bold counterparts.  but until that is implemented, all bold fixed-width fonts are no longer of fixed width.  i can think of no reason why a user would desire this behavior (it contradicts the whole idea of fixed width).  so i say the behavior should be reverted until it is fixed.

> IMHO, this behavior should be user-configurable. I have created a patch which
> implements the respective per-profile option and posted it to KDE Reviewboard
> (http://reviewboard.kde.org/r/4201/). Feel free to review, test and comment.

thank you for the effort, but my counter-humble-opinion is that this effort is misdirected.

for the reason given above, i think it more sense to change bright fonts to saturated and non-bold until the non-fixed-width bolding behavior is fixed.  then, once it's fixed, bright should be reverted back to saturated and/or bold.  if the only use case for your patch is to work around this bug, then it becomes a wasted effort once such a fix is committed.  but perhaps there is another use case which eludes me.

(In reply to comment #25)
> shouldn't the behavior be reverted to just making the color "intensive"?  i
> admit that i don't know what you mean by that phrase--do you mean increasing
> the color saturation?

<long_explanation>

Traditional TTY's have 8 colors (corresponding, in fact, to each of the RGB components being off or on), in addition to several styling bits (e.g. "bold", underline, blink). Depending on the documentation you read, the "bold" bit may be labeled "bright" or "intense".

The reason is that traditional text terminals (think DOS, Linux TTY's before modeset took over, and many BIOS's) would respond to the 'bold' bit not by changing the font, but by using a brighter color, which 'looks' bold when you don't actually have different fonts.

Now... if you look in Konsole's profile appearance, you will see that it describes eight colors, corresponding to those the tty sets... plus eight /more/ colors, labeled "intense", which are used instead of the 'regular' color when the 'bold'/'bright'/'intense' bit is set.

</long_explanation>

So, making the color "intensive" means to use the configured 'alternate' color, e.g. instead of "Color 1", use "Color 1 (intense)". That is, Konsole isn't manipulating the configured color, it is using a /different/ configured color.

Usually you will define your colors in Konsole to match, at least roughly, the traditional text terminal values (such that the effect will be as if you were to make the color brighter), but there is nothing - aesthetic considerations notwithstanding :-) - stopping you from deciding that color 0 should be magenta and intense color 0 should be dark green.

Thx Matthew for your detailed explanation, but IMHO you completely miss the essence of this bug. I don't care what color Konsole renders intense or bright (well, to some extent) the problem is that starting from KDE 4.? developers added *bold* to the make-up of intense or bright rendered characters which is not configurable and misrenders some bold-less fonts very ugly if not illegible, due to an underlying Qt bug.

Even if the proposed patch is a work-around, it is -for me- a VERY welcome one!

> then isn't this a KDE4 regression? 
> shouldn't the behavior be reverted to just making the color "intensive"?

No.  As comment #19 says, it is up to the implementation to decide how to render 'intensive' text.  I think that, this recent rendering bug with certain fonts aside, making intensive text bold looks better.  It also brings the rendering into line with other terminals (xterm, gnome-terminal) so programs developed and tested against those will render similar output in Konsole.  This is a subjective matter so there is an argument, on aesthetic grounds, for including a preference - which there is in recent trunk builds.

This change to make intensive text bold was made 4 years ago with the release of KDE 4.0 but this particular bug as someone mentioned only appeared recently, so the correct thing to do would be to investigate the cause of the bug (whether in Qt, KDE or Konsole) and fix it.  If there is someone reading this who has some time they can spare on the matter, that would be appreciated.

(In reply to comment #27)
> Thx Matthew for your detailed explanation, but IMHO you completely miss the
> essence of this bug.

Actually I was just replying to Ivan's apparent confusion :-). As far as the actual bug, I never cared for tty attribute 1 affecting a typeface change either. (Fortunately I am unaffected as I have configured my 'normal' font to Terminus Bold, so the extra bolding is a no-op. I like my Konsole windows to look like the video built-in text mode fonts, and bold is much closer to that.)

(In reply to comment #28)
> I think that [...] making intensive text bold looks better.

Well, I think it looks awful :-). Thank you for making it optional (not, as noted, that it actually affects me, but...).

I just hit this problem after installing an update to libfreetype6 following the expiry of the hinting patents.

I was using Droid Sans Mono, which doesn't have a proper bold variant. Switching to Consolas, which has a proper bold variant, fixes the problem.

So I'm thinking that the problem is TrueType hinting behavior when generating faux-bold fonts in software.

Hi, I noticed this bolding "feature" some seconds after I had upgraded to KDE4, and I was very annoyed by it. The problem is no matter how well the bold fonts are rendered, if the font size is small enough, some bold characters are very hard to recognize. Maybe not in English or even in Finnish, but for example in Vietnamese or Chinese - yes, I have typed them both in a terminal window.

In my very humble opinion, first and foremost, the characters in terminal display should be as readable as possible, even in small sizes. The very reason why I liked Konsole in KDE3 (and heck, Putty in Windows) was that unlike in Xterm and such, the text was very readable, even when using high-intensity colors. Thus the thinking that making the high-intensity text always bold would be "somehow more right" is flawed. Yes, I have hard time reading high-intensity text when using ANY font on KDE4 Konsole.

Now, this recent bug in font rendering (yes, I think I was hit by it too in Kubuntu Lucid) made this even more apparent and critical. I thought the real issue had been fixed before and this made the bolding optional and configurable, but not. Hopefully this fix stays and everyone gets what they want, bold text for some, readable text for others.

after some further investigation, i found out that the Inconsolata font (among others) is actually rendered with a different width when bold.  i'm not sure if this width is defined by the font or by some font renderer, but it's obviously a bug--the otherwise fixed-width font does not have fixed width when a bold weight is applied to some glyphs but not others.  regardless, i don't think it's a fault of KDE.  the DejaVu Sans Mono font exhibits no such problem.

two different workarounds work for me: setting KDE's monospace font (or Konsole's font) to (1) Inconsolata Bold or to (2) DejaVu Sans Mono at a smaller size.  these both have drawbacks.  the former option removes the ability to have bolder monospace fonts (because they are already bold), but the latter option doesn't look as good (IMHO).  however, both are much better than dealing with clipped text.

regarding the bright/bold dispute: even if this is a matter of preference, the fact remains that some so-called fixed-width fonts are wider when bold.  i think it's safe to assume (but correct me if i'm wrong) that regardless of preference, no one wants their monospaced fonts to become un-monospaced and clipped when bold/bright.  so i see two avenues for recourse: either fix the un-monospacing, or fix the clipping.  again, i don't know who is the culprit behind the un-monospacing.  however, it's clear that Konsole is causing the clipping.  shouldn't this be the primary issue to address in this bug?  it certainly won't be fixed simply by providing a bold/bright option in Konsole's settings--that would still provide bold as a choice, and selecting it would trigger the faulty bold clipping behavior with monospaced fonts that become un-monospaced when bold (e.g. Inconsolata).

as for alternate behaviors to use instead of clipping, i see three options:
    A. when determining the character width, Konsole should examine all font weights/styles/variants that it might possibly apply, and it should use the largest of those widths.  currently it appears to use the width of the default weight/style/variant.
    B. when it encounters a supposedly monospaced font that isn't monospaced, Konsole should fix it.  shrink glyphs that are too wide, and stretch glyphs that are too narrow.
    C. both of the above--choose the largest actual width as the default character width, and stretch any glyphs that are smaller.

stretching and shrinking font glyphs doesn't sound very appealing, but maybe an elegant solution already exists for this.  otherwise, the former option seems much simpler.

Fixed (or whatever you may call it) in 4.5.0 for me! :)

the issue is still present in konsole 2.5.4 on KDE 4.5.5.  i'm using the Inconsolata font, and i have unchecked "Draw intense colors in bold font".

sorry, i meant to say that it is still present when highlighting intense-colored text, but not otherwise.

(In reply to comment #34)
> the issue is still present in konsole 2.5.4 on KDE 4.5.5.  i'm using the
> Inconsolata font, and i have unchecked "Draw intense colors in bold font".

This option does exactly what it says: it disables mapping of intense colors to bold typefaces (the default behavior of earlier versions of Konsole). Previous comments suggest that the problem may have different roots - none of them are (obviously) affected by this setting. Attaching a screenshot would be helpful, thanks!

Created attachment 56167 [details]
illegible bold text while highlighting

(In reply to comment #36)
> (In reply to comment #34)
> > the issue is still present in konsole 2.5.4 on KDE 4.5.5.  i'm using the
> > Inconsolata font, and i have unchecked "Draw intense colors in bold font".
> 
> This option does exactly what it says: it disables mapping of intense colors to
> bold typefaces (the default behavior of earlier versions of Konsole). Previous
> comments suggest that the problem may have different roots - none of them are
> (obviously) affected by this setting. Attaching a screenshot would be helpful,
> thanks!

perhaps i misunderstood, but i thought the problem in this bug arises as follows:

  1. console output marks some text as having intense color.
  2. konsole translates the intense color to bold font.
  3. a monospace font that is wider when bold becomes un-monospaced.

if "Draw intense colors in bold font" is disabled and does what it says it does, then part 2 would never happen.  right?  or is there another way that fonts become bold via konsole output that doesn't involve intense colors?  even if that's the case, it seems that the end result (illegible bold text) is still the one described in this bug.

like i said, the option does work as expected for non-highlighted text.  but highlighted colored text becomes bold and (due to part 3 above) illegible.

i'm attaching a screenshot that demonstrates what i'm describing.

> if "Draw intense colors in bold font" is disabled and does what it says it
> does, then part 2 would never happen.  right?
Right, at least to the best of my knowledge.

> i'm attaching a screenshot that demonstrates what i'm describing.
Sorry, I can't see any problem in your screenshot. I've magnified it several times (you can do it yourself in GIMP or your app of choice) and it's clear that both glyphs have the same "thinkness". The problem is likely atialiasing: atialiased parts of glyphs are dark and thus invisible on your background. As soon as you highlight the text, those antialiased pixels become visible and the glyph may appear bolder. Disable antialiasing (at least temporarily), and the effect should vanish.

If you were using light background (instead of the dark one), the effect would be opposite: when you highlight the text, it would appear thinner.

(In reply to comment #37)
...
>   3. a monospace font that is wider when bold becomes un-monospaced.

not true, at least not in my case

this may be one of the symptomes of the bug too, but in my case (see comment #21) the font becomes "un-monospaced" even when the bold version of the font is NOT wider than the normal version

(In reply to comment #38)
> > i'm attaching a screenshot that demonstrates what i'm describing.
> Sorry, I can't see any problem in your screenshot. I've magnified it several
> times (you can do it yourself in GIMP or your app of choice) and it's clear
> that both glyphs have the same "thinkness".

interesting :-) - to me it is clear that the glyphs have different width even without magnifying ... see the last "ivan" which looks more like "ivar"

> interesting :-) - to me it is clear that the glyphs have different width even
> without magnifying ... see the last "ivan" which looks more like "ivar"
Antialiasing is a bad thing (tm) :-) That's why it is better to use magnification - thus you can clearly distinguish the glyph (solid color) from antialiased part (shades of different colors). Or, at least, it would be clear that it is a bug and not a misconception.

You can check it another way: open OOo Writer, choose the same font as in your Konsole, recreate the text and colors, and add bold attribute to one of the words (preferably adjacent to the same word without bold attribute on the page).

(In reply to comment #40)
> > interesting :-) - to me it is clear that the glyphs have different width even
> > without magnifying ... see the last "ivan" which looks more like "ivar"
> Antialiasing is a bad thing (tm) :-)

well, we can agree upon that, however ...

> That's why it is better to use
> magnification - thus you can clearly distinguish the glyph (solid color) from
> antialiased part (shades of different colors). Or, at least, it would be clear
> that it is a bug and not a misconception.

using magnification I can clearly distinguish that the letter "n" at the end of the last "ivan" is shifted three pixels more to the right side than in previous five "ivan" occurences - this has NOTHING to do with antialiasing!

Created attachment 56168 [details]
illegible bold text while highlighting (no anti-aliasing)

(In reply to comment #40)
> > interesting :-) - to me it is clear that the glyphs have different width even
> > without magnifying ... see the last "ivan" which looks more like "ivar"
> Antialiasing is a bad thing (tm) :-)

then what do you suggest for making fonts look smooth instead of jagged?  afaik, anti-aliasing is exactly the solution to this problem when you have a display that consists of a finite array of regularly shaped fixed pixels.  just because anti-aliasing might make it harder to track down some problems doesn't mean it's a bad solution.

> That's why it is better to use
> magnification - thus you can clearly distinguish the glyph (solid color) from
> antialiased part (shades of different colors). Or, at least, it would be clear
> that it is a bug and not a misconception.

the new screenshot shows the same problem without anti-aliasing.  you can see more clearly that the letters are wider (for example, the 'a' is 6 pixels wide instead of 5) but the spacing between them is the same.

Created attachment 56169 [details]
oowriter wider bold text (no anti-aliasing)

(In reply to comment #40)
> You can check it another way: open OOo Writer, choose the same font as in your
> Konsole, recreate the text and colors, and add bold attribute to one of the
> words (preferably adjacent to the same word without bold attribute on the
> page).

this new screenshot shows that the bold font is also wider in oowriter.  it doesn't cause illegibility because unlike konsole, it doesn't fix the positions of non-bold characters to a grid.

> illegible bold text while highlighting (no anti-aliasing)
Yeah, this looks convincing. Try to change color scheme then (Edit Profile > Appearance) - some of them are explicitly specifying different colors as bold; it is also not influenced by the setting (and it is intentional - if you don't like a scheme with "bold" colors, just use another without them). For instance, 'White on Black' scheme does make some colors bold, 'Linux Colors' doesn't. If this doesn't help, try to use different font and see if this helps.

> then what do you suggest for making fonts look smooth instead of jagged? 
Just use good fonts at their native DPI (but it is out of scope of this discussion).

Konsole 2.6 on KDE 4.6.0 seems to fix the problem with "Draw intense colors in bold font" not affecting highlighted text.

but the original issue still remains--some monospace fonts are wider when bold, thus not actually monospace--and disabling "Draw intense colors in bold font", while useful, is merely a workaround that resolves the issue by disabling a troublesome feature.  i don't know enough to tell where this problem originates, but i can confirm that it's not specific to konsole.  however, it manifests worse in konsole than in other applications because konsole apparently locks the positions of non-bold characters to a grid, so the end of each sequence of bold characters is cut off.

is it possible to work around this problem in konsole or in whatever font renderer it uses?  i suggest locking every character (bold and non-bold) to the grid so that at worst, only one or a few pixels of each bold character is cut off, rather than whole letters as now happens with long sequences of bold characters.  even better than this might be to scale each bold character to fit within each character tile of the grid.  these would be hacks, sure, but they would provide better results than the current behavior.

A possible workaround is to disable embolding in your local .fonts.conf e.g. for Inconsolata by adding the following configuration and recreating the font cache using 'fc-cache -f' :

    <match target="font">
        <test name="family">
            <string>Inconsolata</string>
        </test>
        <!-- check to see if the font is just regular -->
        <test name="weight" compare="less_eq">
            <const>medium</const>
        </test>
        <!-- check to see if the pattern requests bold -->
        <test target="pattern" name="weight" compare="more">
            <const>medium</const>
        </test>
        <!--
          set the embolden flag
          needed for applications using cairo, e.g. gucharmap, gedit, ...
        -->
        <edit name="embolden" mode="assign">
            <bool>false</bool>
        </edit>
        <!--
         set weight to bold
         needed for applications using Xft directly, e.g. Firefox, ...
        -->
        <edit name="weight" mode="assign">
            <const>bold</const>
        </edit>
    </match>

*** Bug 283079 has been marked as a duplicate of this bug. ***