Bug 567987

This is very often indicative of a video driver problem.  what video driver are you using?

(hint: binary blob nvidia driver users have reported similar issues wrt bitmap font handling recently).

It's not a video driver problem -- it's the wrong font, not a corrupted font.  Also the same font doesn't show up as a problem in non-KDE apps; it's excusively a KDE problem and only appeared this morning in the KDE 4.4 update.

For the record I'm using the intel video driver.

OK, I can reproduce the problem.  eww indeed.

I'd venture there's something subtly wrong with miscfixed's font metrics.


I'm of a mind to continue to track this upstream, unless you think there's something fedora-specific here to do?

I don't think there's anything wrong with MiscFixed, more the handling of MiscFixed by KDE -- the same font is fine everywhere else.  (Although someone did mention that a possible cause might be that the bold version has different metrics, but I'm not sure that that is the case.)

This also isn't Fedora-specific but I put the bug here so that it can be tracked for Fedora and also found by people having the same problem.   I'm sure there are some.

It's a Qt 4.6 issue, not a KDE issue.

Bug 474171 and bug 498460 come to mind.

> Bug 474171 and bug 498460 come to mind.

Nope, it's definitely not either of those.

In the upstream KDE bug I referred to there's a reference to http://bugreports.qt.nokia.com/browse/QTBUG-7255 but that isn't the problem either: I'm not using the nvidia driver (this is intel) and I don't have the speed problem.

Interestingly, perhaps, when I was dragging the slider to show different font sizes to see if there was a performance issue, some of the displayed fonts were fixed-width, some weren't.  For example, 10pt (the one I normally use) should correspond to the old 6x13 bitmap font (-misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1) but looks like a bitmaped Times Roman; but 9pt looks like the old 6x10 font (-misc-fixed-medium-r-normal--10-70-100-100-c-60-iso8859-1) and other fonts are either various fixed-width fonts or various serif fonts.

So while this stands a good chance of being a Qt problem; it's the wrong-font or corrupted-font problem, not the rendering speed problem.  And it's equally definitiely not an issue with the graphics driver, not least because the problem arose with the KDE 4.4 / Qt 4.6 update.

For completeness, I've just tried this on my other machine which has an nvidia graphics card.  I see the same wrong font instead of MiscFixed 10pt both with the nouveau driver and the nvidia driver.   I don't see any performance problem with the nvidia driver, although I do see a different selection of fonts, all proportional, all serif (probably because the screen reports a different dpi).

Oh yes, and since I can see the bad font in qtconfig-qt4 I'm pretty sure that this is a Qt issue.

I first noticed this issue after 'yum update' updated my FC11 system to KDE 4.4.0.  In my case, MiscFixed looked as though it were a proportional font.  Other fonts including Liberation Mono were displayed correctly as fixed width.

I've discovered that "fooling around" with an app that shows an incorrectly displayed fixed font can sometimes make the font display correctly.  With konsole, I did this in "Edit Current Profile" by first switching to a correctly displayed fixed font such as Liberation Mono and clicking OK.  I then reopened "Edit Current Profile", selected "MiscFixed", and clicked OK.  At this point the font displayed correctly.  The font is also correct when I open new instances of konsole.

Playing with settings does not fix it for me. Sorry, I cannot confirm this.

I noticed that MiscFixed fonts were never listed by KFontInst, nor could they be picked up from /usr/share/fonts/bitmap. This was even with qt-4.5.3. Konsole somehow managed to work with them. Since qt-4.6.2, it cannot.

Is it possible to check if qt-4.6.2 recognizes MiscFixed at all?

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

Thank you for taking the time to report this issue to us.  This is an issue which is best addressed by the upstream developers.

Please file a report at bugs.kde.org , and when done add the upstream report info to this report.

We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates.

Thank you for the bug report.

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

There are plenty of bugs filed upstream regarding poor handling of bitmap fonts:

https://bugs.kde.org/show_bug.cgi?id=174832
https://bugs.kde.org/show_bug.cgi?id=193369
https://bugs.kde.org/show_bug.cgi?id=217306

The last one sounds particularly similar. 

Can we get the official word on the status of bitmap font support?

Created attachment 396897 [details]
Bitmap fonts are skrewed at certain sizes only!

In the attached snapshot, you will see that bitmap fonts are screwed at certain sizes only!

MiscFixed 11 points in the left konsole looks very bad.
MiscFixed 15 points in the right konsole looks great.

The main puzzle is that these sizes have nothing to do with font metrics.

The left is supposed to use 9x15.pcf as illustrated in kfontview.
The right is using 10x20.pcf as illustrated in kfontview

Comment #11 -- As I said in comment #9, you can see this problem in qtconfig-qt4 so it's a Qt problem, not a KDE problem

Comment #14 -- None of these are at all related to this bug

Comment #15 -- this is the effect I described in comment #8

Comment #11 -- Requested info.

This bug is still most like the upstream KDE bug I originally referenced (see "External Bugs")  However, since this is actually a Qt Bug I have created
http://bugreports.qt.nokia.com/browse/QTBUG-8620

(I'm sure I used to be able to mark the bug as having the requested information but I can't see that now.  Sorry.)

It's all about Qt trying to scale a bitmap font. I was playing with DPI settings and that also screws bitmap fonts.

See this bug report as well. Why did they invalidate it?
http://bugreports.qt.nokia.com/browse/QTBUG-6513

> It's all about Qt trying to scale a bitmap font. I was playing with DPI
> settings and that also screws bitmap fonts.

I don't believe that this is the case.  This font isn't scales at all.  If you change the DPI settings you will change which bitmap font is selected and when Qt -- with the right dpi you will be able to select a bitmap font that exists and not select (presumably) a fallback font.


> See this bug report as well. Why did they invalidate it?
> http://bugreports.qt.nokia.com/browse/QTBUG-6513    

It's invalid because it isn't a bug -- the bitmap font _should_ be scaled and previously it wasn't.

(In reply to comment #19)
> > It's all about Qt trying to scale a bitmap font. I was playing with DPI
> > settings and that also screws bitmap fonts.
> 
> If you change the DPI settings you will change which bitmap font is selected
> and when Qt -- with the right dpi you will be able to select a bitmap font
> that exists and not select (presumably) a fallback font.

I agree that this is how it is supposed to work. This is not, however, called 'scaling' as meant in 'scalable' fonts like TrueType. Bitmap fonts are *not* scalable, instead a different set of raster images should be picked.

Qt is either tries to scale the raster image, or fall back, or whatever - it is not doing the right thing with bitmap fonts.

> Qt is either tries to scale the raster image, or fall back, or whatever - it is
> not doing the right thing with bitmap fonts.  

The problem font is NOT scaled.  MiscFixed 10pt corresponds exactly to the old 6x13 font and is not scaled at all.  This is not a font scaling issue, this is a font selection issue.

For anyone else looking at this: see the upstream bug at http://bugreports.qt.nokia.com/browse/QTBUG-8620

Qt fails to find appropriate MiscFixed at the requested size and falls back to some other font. What we see is definitely not MiscFixed. I checked all MiscFixed sizes using kfonview, which renders them all beautifully. 

The fall back font is some default font, not even monospaced. By the way, your fall back font is not the same as mine (see attachment above).

Finally, Kfontvew reports height of the bitmap font at its metric, which is probably correct. Konsole offers sizes based on the average of height and width, which is probably too clever.

Well, let's track this upstream then, it's clearly an upstream Qt bug (and FWIW it's NOT the same as QTBUG-7011 = bug 550177 which is an NVidia driver issue), we need to wait for an answer from Nokia.

Why can't I re-open this bug?

From the upstream bug:
---------------------------------------
        Status: Closed  (was: Reported)
    Resolution: Invalid

Using a plain Qt build from the 4.6 branch on F12 the font looks fine. Its still a bitmap font, naturally, but the disruptions seen in Konsole are not there.

If you disagree please make a standalone, runnable Qt application that shows the problem and attach it.
---------------------------------------

Either this is a KDE bug or its a Fedora bug.  Since I see the same mangled font in qtconfig-qt4 my money is on the latter.

It's definitely a Qt bug. Unfortunately, upstream Qt always tries to explain away their bugs or point fingers towards somebody else.

I also cannot reproduce this, probably for the same reason Qt upstream cannot reproduce it.

To reproduce this bug, you should try MiscFixed font at a few different sizes.
I found that some sizes do work, while most others don't.

Well, looking at the comments from upstream, actually, the upstream developer was able to reproduce it on F12 with our packages, but not with a vanilla Qt. Weird.

And actually, I also see this with MiscFixed, I was confusing it with another report where all bitmap fonts caused trouble, which I could not reproduce.

As the problem is not upstream, then, can someone please re-open this bug?  (I wish I could re-open my own bugs!)

Re-opening.  Interesting indeed.

Created attachment 397957 [details]
Comparison of broken fixed-width font in Konsole, vs GNOME terminal.

I originally attached this shot to report 568574, which was marked as a duplicate. It shows konsole's font rendering compared to the same font in GNOME terminal. Not only is the rendering broken, it also affects editing, as the cursor is shown offset from its actual position.

> Not only is the rendering broken, it also affects editing, as the
> cursor is shown offset from its actual position.

That's because it's a proportional font.  The cursor is position according to some fixed width (1en, 1em, mean; something like that).   Terminal emulators and proportional fonts don't mix.

Assuming that this is specific to Fedora's qt and not present in vanilla qt, bisecting this bug seem straightforward: halving Fedora's qt patches by dropping/reintroducing them. Is this a sensible approach to finding the cause of this bug? What do you think?

Youre welcome to try that, however, I'm not convinced that it is a qt bug specific to fedora's packaging.  Honestly, we carry a low number of patches, and only one affects fonts at all.  And, even if that patch *did* make a difference, it still most likely means either an internal qt bug, or highlights on elsewhere in the font stack.

Is Patch15 the only one concerned with fonts? It seems irrelevant.

Upstream QTBUG-8620 seems to be able to reproduce this bug only with Fedora's qt and closed the issue there. The ball is in Fedora's court.

I strongly doubt this is a Fedora bug.

Upstream tested with the current 4.6 branch vs. our 4.6.2 package. There may be a post-4.6.2 fix in the 4.6 branch which fixes this.

Any chance of getting a qt-4.6.3 update that was just released?

yes, a qt-4.6.3 is being prepared for testing.

Alexei, could you please test the 4.6.3 whether this issue is fixed in this release?

http://koji.fedoraproject.org/koji/buildinfo?buildID=177449


thanks

Unfortunately not. The bug is still here.

Let me rant a bit here:

The guy on qt bugzilla *tried* vanilla qt and claims that this is not a qt.
You guys just dismissed him *without trying* anything. Guess who I am to trust?

Rebuilding/repacking for four F11/F12/F13/F14 release streams every time is 
busy doing busy work, which is frankly not productive.

I still don't know why upstream can't reproduce this with vanilla Qt. I thought it might have been fixed post 4.6.2, but it looks like that's not it.

qt developer wasn't dismissed, I *did* test a vanilla build.  I find his statement hard to believe, there are quite a few people seeing these over a fairly broad number of distros ( see all the comments on http://bugs.kde.org/show_bug.cgi?id=217700 )

Rex, why don't you confront him there? 

Again, see my Comment 22 with respect to kfontview (aka pure Qt app?).
Kfontview renders those fonts correctly when pointed to a specific file
for a specific size. How do you explain that?

Oh wait, kfontview is not trying to reinterpret the font size. So is it Qt 
or KDE who deals with size matching?

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I can confirm that the bug still exists in Fedora 13.  I haven't tried Fedora 14 yet.

Most sizes of MiscFixed actually show up as some proportionally spaced font rather than fixed width and this is really not good for a terminal emulator!

This bug is fixed in Fedora 14 under both KDE 4.5.2 and 4.5.3.  You can close it now.

Well, I guess this is an argument for pushing 4.7.x to F13, it must be Qt 4.7 which fixes this.

yes, it's surely a bug in qt.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.