Version: (using KDE Devel)
Installed from: Compiled sources
Compiler: gcc 2.95
When selecting and then using the "console" fonts (which is the font within the konsole subdir of kdebase) then it seems to be displayed incorrectly. Each character seems larger than expected and also there is a single space between each letter (ie the character width appears to be twice what it should be).
This does not happen when using the font in an xterm (for instance).
Created attachment 688 [details]
Snapshot of the effect I am describing
This shows the effect when selecting the font within the select font dialog of
konsole - see the sample text on the bottom of the font selection dialog, and
on the actual screen area of konsole
I have the same problem with the same font, and others like nexus or outcast since my last debian
update Thursday 9th.
And what did it update? Qt and/or KDE packages? To what versions?
Created attachment 805 [details]
Code snippet showing how to reproduce problem
This is NOT a problem with konsole, but rather JUST about how the FixedPitch
attribute of a font changes how it is displayed. This code snippet is from a
very simple QDesigner Application that just uses a button click to toggle the
FixedPitch attribute of the default font being used to display in a QLineEdit.
When FixedPitch is set the display width of the text doubles.
Because KFontDialog with the second parameter set to TRUE returns a QFont with
this attribute set, and because Konsole uses the font that is returned, the
effect shown in the first attachment occurs.
I am also seeing this behaviour. KDE 3.1 final from source on RH8 XFree86-4.2.0 Fontconfig-2.1 (this upgrade did not help) QT 3.1.1
I have done further analysis of this problem. Its XFT returning what appears to be
bogus font widths with the "Fixed Pitch" attribute is set. QT uses that bit to request a
font which is reported by XFT to be either XFT_MONO or XFT_CHARCELL. XFT
returns what looks like a matching font but the character widths, as obtained from
XftTextExtent16 are too large.
The actual problem I reported is related to the Console font. XFT seems to reckon this
is large (font widths in proportional mode of approximately 11 pixels for a 12point font -
thats more like a 10 or 9 point font) and in monospaced mode it is returning a font width
of a massive 26 pixels.
I have attempted to report the bug at debian (whose packages I am using) and on the
fontconfig mailing list.
I have a similar problem. I see helvetica font with larger characters, but I also see all fonts as the same thing.
It is also possible to work around the problem by editing ~/.qt/qtrc and changing the line
"enableXft=..." from true to false.
It appears with enableXft set to true that (with the fonts that I have installed) "console"
font is being "best matched" as "verdana" by xft. When qt is left to do it, it seems to find
Thank you very much. Editing qtrc and chaging enableXft to false solved the problem!!!
I think I now know at least one part of the problem related to this bug. The first part of
the problem is that a request to display the "console" font confuses Xft/fontconfig -
because it can't find a match against that family name. It instead uses the Style Hint
given it by qt to locate the nearest font (which will depend on the fontconfig
configuration). Before qt caches the font - it asks xft for it - which asks fontconfig which
looks for it in the fonts.cache-1 file in the appropriate directory. It does not find console
(but instead the name is console8x16.pcf)
This is because when fontconfig creates the font.cache-1 file in each of the font
directories it asks freetype to look up the font from the font filename at give it its
parameters. Due to a bug in freetype 2.1.3 (fixed in cvs I am told) the routine that
decompresses compressed fonts (console is one of these) reports a file format error
against the font file and hence fails to get its parameters into the font cache.
Fontconfig works round the problem by creating the family name from the file name.
However, even with this bug fixed there is still a problem with the console font that
means that freetype doesn't get its name right. I believe THIS IS A BUG in the
console8x16.pcf.gz and console8x8.pcf.gz files distributed with KDE.
The file has "properties" in it, with a string defining the property type and a string
defining the property value. These fonts use FAMILY as the property type and console
as the property value. I have sampled some other fonts and they have FAMILY_NAME
as this property type. Freetype is only looking for the string FAMILY_NAME. Hence it
reports a null family name when asked and fontconfig therefore writes the filename into
the font.cache-1 file.
(I have asked for pointers to the pcf specification on the freetype mailing list to try and
confirm what I am saving)
I note that someone has fixed the fonts in cvs. So this nearly solves the problem. I
have also discovered that what happens now is that fontconfig is searching for a
nearest fit to "fixed" 9 point on a 100dpi screen and is locating (at least on my system)
a font called
This font seems to have an "Additional Style" hint which font config ignores.
I have overcome this by adding the following text to /etc/fonts/local.conf
<edit name="family" mode="assign" binding="strong">
Now konsole starts perfectly with the console font as the "normal" font.
I have been having a conversation with the fontconfig author (Keith Packard) on the
fontconfig mailing list and the correct thing for an application (such as konsole) to
do if it wants a generic font is NOT to used "fixed" as the family name but use a
generic name (such as "monospace"). That way the fontconfig configuration file
can be used to find a user specific font.
So, is there a solution for this problem (except for the workaround by editing qtrc)?
I built and installed xfree-cvs, freetype-2.1.4 and kde 3.1.2 and still have too much space
between the characters of any of the fixed width fonts.