As Branden said in his last mail, this bug has many aspects, some of which 
are related to fontconfig and some of which are caused by Xft.

> c) some Japanese fonts had Unicode characters in them and some very wide 
> Japanese characters - this was causing the strange font metric for fixed 
> font.

Xft does something wrong -- it takes the spacing attribute which is used 
to select fonts and applies it to the rendering process.  When an 
application requests a monospaced font, all of the characters will be 
forced to the same width.

I don't know if I can fix this without breaking things.  What I suggested 
to Owen Taylor was that Pango (used by Gtk+ for text drawing) smash this 
attribute after the font was selected but before the characters were 
drawn, this disables the broken Xft behaviour nicely while not affecting 
non-Pango applications.  The same thing could (and probably should) be 
done by Qt.

> d) I think there is confusion in both Konsole and QT about what to do about
> "null" family names - and how to just ask for a generic name. 

I think the bug is just in Konsole; asking for 'fixed' will give you the 
fixed family, of which there are a surprising number of horrible bitmap 
fonts.

Get Konsole to use 'monospace' instead and this problem (and e) should 
disappear.

> f) Fontconfig is matching family name "fixed" with a Japanese font from
> within xfonts-base.  This is because the font 

That's strictly a pixel-size issue; this Japanese font has the closest 
pixel size to that requested by the application, or perhaps both this and 
the desired face have the same pixel size and fontconfig just selected 
this one at random.

The problem here is that these two completely different fonts use the same 
family name; that's a bug in the fonts themselves, one which almost 
certainly cannot be fixed without breaking some application somewhere.

With fontconfig 2.3.1, I would suggest you disable all bitmap fonts and 
then enable precisely the bitmap fonts you do want, this is possible in 
your ~/.fonts.conf file, the fonts-conf(5) manual page has a section on 
the <selectfont> element which does this.

> g) the xserver seems to fail to start if it does not have access to a "fixed" 
> font.  This seems to be the case even if all the applications are using 
> libxft/fontconfig/libfreetype.

The X server must have at least 'fixed' and 'cursor' to start.  I created 
versions of these fonts which can be compiled directly into the server 
binary so that it could start with no extra files, but that isn't enabled 
in the Debian XFree86 packages.

> which implies there is now the ability to bind with the same strength as the 
> pattern you are replacing so my pattern is probably out of date]

Yes, you can use <edit name="family" mode="prepend" binding="same"> 
element in fontconfig 2.3.1, which will let you redirect this misguided 
application to the right fonts.

-keith


Attachment: pgpo3sFfMAWoJ.pgp
Description: PGP signature

Reply via email to