Debian Bug report logs - #179519
libxft2: monospaced fonts giving wrong font metrics

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: submit@bugs.debian.org

Subject: Monospaced fonts giving wrong font metrics

Date: Sun, 2 Feb 2003 21:32:34 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Package: libxft2
Version: 2.1-7

I have been trying to track down a problem in KDE/Konsole in which the fonts 
seem to display all wrong. (See http://bugs.kde.org/show_bug.cgi?id=52538 
 for a description - and also a screen dumpt is attached).

In order to track down what is happening, I have a small QT only app which 
creates a simple one line display of text ("Pack my box with five dozen 
liquor jugs") and toggles the "Fixed Pitch" attribute of the attached font. I 
have run this with the default Helvetica font and with the Console font that 
kde provides for using with konsole.

With a debugger I have managed to track down what qt does. It asks xft for a 
unicode font which matches the font family, weight, slant etc - including 
checking whether its an not fixed pitch (XFT_PROPORTIONAL) or  fixed pitch 
(XFT_MONO or XFT_CHARCELL - strictly it actually checks for value > 
XFT_MONO).  With a handle to that font, it then asks for the width, one by 
one of each character in the string -  I am not an expert in libxft2, but I 
think it is using XftTextExtent16 to fetch this metric (maybe from a cache) 
based on a screen resolution of 100dpi.

With Helvetica, in proportional mode, its getting response, that varies by 
character from 4 pixels (space) to 9 pixels ('m'). This is drawn as would be 
expected and looks great (see below related to drawing). If I ask for 
Helvetica in monospaced, I get the same characters, but the width of each 
character is reported as 12 pixels. This obviously stretches the text out so 
that it looks ugly.

A word on drawing the text.  As far as I can make out, QT is asking XFT to 
render the font as a single command for the complete string.  However, QT is 
keeping track of the cursor position relative to each character based on the 
width values talked about above.  Since the cursor and the text remain in 
perfect combination regardless of whether they are stretched or not then I 
assume XFT is rendering the fonts according to the metrics it reports.

I repeated these tests with the the Console font (debian package 
xfonts-konsole downloaded from Ralf Nordens debian packages)

With the Console font in place I get wider widths and a very bold looking 
text. In proportional mode, they look reasonably spaced - but do very from 
character to character (despite suposidley being a monospaced font).  In 
monospaced mode each character is reported as an enormous 26 pixels wide 
(this on a point size that is supposed to be 12).

I think there might be two problems interacting.  This all started when I 
first installed fontconfig.  I do not believe that the font displayed when I 
request Console is actually the console font.  It looks a lot blacker and 
larger than it used to look before fontconfig was installed.  Its as though I 
am being redirected to another font.

However, the monospaced width problem occurs also with the Helvetica font - an 
this definately displays in the same way as before when it is proportional.

- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+PY5yuFHxcV2FFoIRAtVhAJ9hbHRtMJVFgpMXMWMcSx9Y7UWziQCfSqMc
yrOo5fqerbKl8TsVSUzCY2Q=
=Y1ju
-----END PGP SIGNATURE-----

Message #10 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Chris Cheney <ccheney@cheney.cx>

To: 179519@bugs.debian.org

Subject: <aol> me too </aol>

Date: Sat, 8 Feb 2003 00:22:25 -0600

I saw this bug as well, it is related to xft2/fontconfig afaik, before I
switched kde to compiling against it I didn't notice this problem. Here
is a more detailed account of what I looked at. Also medium font on
konsole is very screwed up looking and iirc Kevin Puetz (puetzk on
freenode) said it was getting a japanese font by accident.

http://marc.theaimsgroup.com/?l=xfree-fonts&m=104199181813410&w=2

Thanks,

Chris Cheney (calc)

Message #17 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: 179519@bugs.debian.org

Subject: Console is replace by verdana

Date: Sat, 8 Feb 2003 12:55:55 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I did some further checking and when qt asks xft to do a best match - I think 
the sequence of calls is (see QFontPrivate::bestXftPattern in qfont_x11.cpp 
in the qt source code)


pattern = XftPatternCreate();

then various calls like

    XftPatternAddString (pattern, XFT_ENCODING, "iso10646-1");
...
// and this is the call that determines if a monospaced font is asked for
    if (mono_value >= XFT_MONO)
 	XftPatternAddInteger (pattern, XFT_SPACING, mono_value);
...


and finally

result = XftFontMatch(QPaintDevice::x11AppDisplay(),
			  x11Screen, pattern, &res);


It is an "unparsing" of this result that shows its verdana (qt is using the 
unparsed string to create a dictionary of loaded fonts)


- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+RP5fuFHxcV2FFoIRAmrZAJwJgOaLdgrvI5kWvFsRXXsymeYZBACfYdwt
042kYOrzsVzYdjwzL+f3EEc=
=gUYV
-----END PGP SIGNATURE-----

Message #22 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: debian-kde@lists.debian.org

Cc: 179519@bugs.debian.org

Subject: Re: antialiasing on sid, kde3.1

Date: Mon, 10 Feb 2003 19:15:57 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 10 Feb 2003 1:13 pm, Vladimir Wiedermann wrote:
> hi,
> I'm new here. I have read part of history of this mailing list, but i
> didn't find answer to this:
>
> I got sid, kde3.1 from sid and fontconfig although i have used
> font-intaller on older Karolina's kde and installed some truetypes from
> windows.
>
> And a problem:
>
> Antialiasing won't work, until reconfigure fontconfig.
> After reconfiguring fontconfig - konsole fonts looks terrible - lots of
> squares in midnight commander and so on..
> Also when i choose different font, most of avaialable fonts look the same.
>

I have reported this as a bug against the libxft2 package in debian :-

Bug#179519:  Console is replace by verdana

and at kde against konsole:-
     
http://bugs.kde.org/show_bug.cgi?id=52538


I have been doing some debugging of the problem and it seems to be that the 
fontconfig library is somehow not matching the fonts properly.  If it gets it 
a little wrong you get the effect you mention above.  If it gets it badly 
wrong, qt notices and then bypasses fontconfig and accesses the fonts 
directly (libfreetype ?). 

My problem is that it seems to change as you rebuild qt. Although my main 
version of libqt-mt and kde is debian, I have one account where the 
LD_LIBARY_PATH points to version of qt-copy from the kde head CVS.  I have 
been using that account with a small qt only application that demonstrates 
the problem.  Yesterday I updated qt from CVS HEAD, rebuilt it and the 
problem went away.  I have only had time so far to run the debugger quickly 
to find out why, and I have discovered that the font being returned by 
fontconfig is so far removed from what was expected that qt then gave up and 
tried to look for it directly. 

I am continuing to search.

- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+R/pxuFHxcV2FFoIRAuVLAJ40FjBF+V+C7vXfRFkGRPmadheiZgCgjtcv
PLDgMTcS/4t43ZgN+NCbvVA=
=sqOc
-----END PGP SIGNATURE-----

Message #27 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: 179519@bugs.debian.org

Subject: Correction to last report

Date: Mon, 10 Feb 2003 21:59:52 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My last comment was incorrect.  Qt had accidently been linked to libXft.so.1 
instead of libXft.so.2

- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+SCDYuFHxcV2FFoIRAryKAJ9GdKQao5ZA3eK4J3GBeK8FEEDamgCaA2Sb
2DOeQY5CbYcaIRq/WkKDPaM=
=VcAs
-----END PGP SIGNATURE-----

Message #32 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: 179519@bugs.debian.org

Subject: It seems to be a problem with the cache

Date: Sat, 15 Feb 2003 19:01:44 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have been further exploring why I get the "verdana" rather than "console" 
trying to use the console font in an application.

Fontconfig is trying to match the requested font ("console") with its own list 
of fonts.  It tries a match on a number of parameters in order of priority.  
One of the highest values is the family name (ie should be "console") but it 
can't find that.

As a fallback it looks for a font of the style "sans".  Font config changes 
"sans" into "sans-serif" and from there into the list of fonts given in 
/etc/fonts/fonts.conf as aliases for sans-serif.  Verdana is the head of that 
list and so matches.

The reason that it cant find a font with the family name console is that the 
family name appears to have been set to "console8x16.pcf" for the "console" 
font in /usr/share/fonts/fonts.cache-1. 

I have yet to discover why it gets set to that in the first place.  
- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+To6YuFHxcV2FFoIRAnb4AJ0XqRf19vddU/DkMde91fL4AZvQhQCgp3zW
60cbAw41qXTeUAFXsreeUqk=
=+qgO
-----END PGP SIGNATURE-----

Message #37 received at 179519@bugs.debian.org (full text, mbox, reply):

From: peter@hawkins.emu.id.au (Peter Hawkins)

To: 179519@bugs.debian.org

Cc: 179519-submitter@bugs.debian.org

Subject: X version?

Date: Sun, 16 Feb 2003 17:35:24 +1100

Hi...

To the submitter of #179519:

What version of X did you have to cause #179519? I have experienced a
similar problem due to pre-release XFree86 4.2.99 debs (even after I
downgraded to the 4.2.1-5 in Sid). Running fc-cache as root fixed the problem
for me. Perhaps you could try that?

=)
Peter

Message #45 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: peter@hawkins.emu.id.au (Peter Hawkins), 179519@bugs.debian.org

Subject: Re: Bug#179519: X version?

Date: Sun, 16 Feb 2003 08:06:28 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 16 Feb 2003 6:35 am, Peter Hawkins wrote:
> Hi...
>
> To the submitter of #179519:
>
> What version of X did you have to cause #179519? I have experienced a
> similar problem due to pre-release XFree86 4.2.99 debs (even after I
> downgraded to the 4.2.1-5 in Sid). Running fc-cache as root fixed the
> problem for me. Perhaps you could try that?

I am running 4.2.1-5. I never ran any pre-release debs.

Perhaps more importantly I am running libfreetype6 2.1.3

After further checking, fc-cache uses the freetype library to populate the 
font.cache-1 file.  fc-cache is searching the font directories for files and 
for each one it gets it asks the freetype library to create a "face" given 
the file name (and an id of 0 - don't understand that bit yet), and then from 
there it asks the "face" for the family name.  libfreetype is returning a 
zero length for this name.  As a result fc-cache says that it can't get a 
font family and creates one from the file name.  This is what gets written to 
the font.cache-1 file.  The rest of the information in this bug report 
explains why this leads to a "verdana" font being displayed instead of the 
requested "console".

- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+T0aEuFHxcV2FFoIRAitRAJ9CGNCRdxFDwkb5RuI0QYeMyEv3agCgk8Xq
iWTCndXCbsimhhqt8SoIQQU=
=A9yz
-----END PGP SIGNATURE-----

Message #50 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: 179519@bugs.debian.org

Subject: Problem partially solved.

Date: Tue, 18 Feb 2003 20:27:38 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have tracked down at least part of the problem.  Carrying on from the 
previous information, libfreetype is returning invalid information to 
libfontconfig/fc-cache information whilst it writes the fonts.cache-1 file

The reason for this is twofold

a)  There is a bug in the decompression routine in libfreetype 2.1.3 causing 
it to reject the "console" file as the wrong format.  This has been fixed on 
cvs with the following patch

and
- --- freetype-2.1.3/src/gzip/ftgzip.c    2002-11-06 23:32:54.000000000 +0100
+++ freetype-2.1.3.new/src/gzip/ftgzip.c        2003-01-10 18:24:46.000000000 
+0100
@@ -177,7 +177,7 @@
     (void)FT_STREAM_SKIP( 6 );
 
     /* skip the extra field */
- -    if ( head[3] && FT_GZIP_EXTRA_FIELD )
+    if ( head[3] & FT_GZIP_EXTRA_FIELD )
     {
       FT_UInt  len;
 
@@ -187,7 +187,7 @@
     }
 
     /* skip original file name */
- -    if ( head[3] && FT_GZIP_ORIG_NAME )
+    if ( head[3] & FT_GZIP_ORIG_NAME )
       for (;;)
       {
         FT_UInt  c;

b)  The two console fonts distributed by KDE have the property name FAMILY 
rather than the property name FAMILY_NAME where the "console" family name is 
defined.  libfreetype only respects the later as a valid property string.  I 
have reported this to kde on the original bug report.




- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Upc6uFHxcV2FFoIRAp4/AKCNjugEZVyE6xI5wx1Z1v9DLgLu6QCeJnmQ
4EedgZSy3+p0KIzbTwxQiDg=
=s9SH
-----END PGP SIGNATURE-----

Message #55 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: 179519@bugs.debian.org

Subject: Konsole fonts

Date: Fri, 21 Feb 2003 22:43:44 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

the kde cvs now has updated console fonts which have the FAMILY_NAME property 
correctly specified.
- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+VqupuFHxcV2FFoIRAmXyAJ4jGeF30ABiI7xQL9VtpXzmyqBYDQCgoKqj
bhq9061ONfHhUsJIHWsByRg=
=7zKo
-----END PGP SIGNATURE-----

Message #60 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: 179519@bugs.debian.org

Subject: Reason the fonts are wrong

Date: Tue, 25 Feb 2003 20:41:32 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know this is a little OT from the original bug report - but since working my 
way through and correcting the problems that have arisen, the original 
problem of double width fonts has not surfaced on my configuration recently.  
The only issue that I have been puzzled with is why the font in kde's konsole 
looks so ugly.  I now have the answer.

Fontconfig - whilst searching for a pattern that matched does NOT take the 
"Additional Style" field of the font into account.  Within xfonts-base 
package (which you can't remove because the xserver fails to start if you do) 
there is a font file /usr/X11R6/lib/X11/fonts/misc/12x13ja.pcf.gz.

This font has the "additional" style of ja - but in other respects appears 
like the "fixed" fonts also in that directory.  By some quirk of fate (at 
least on my system) when fontconfig is searching for a "fixed" font of size 9 
points to display on a 100dpi screen - this one is seen as the closest fit.  
However the glyphs that this font displays are completely different from the 
other "fixed" fonts in the xfonts-base package.

This might be considered a bug in xfonts-base, but I expect there is a good 
reason why this particular font is in the package.

The alternative is to use the /etc/fonts/fonts.conf file to redirect config 
away from these fonts and to some other file.  Unfortunately the obvious
<alias>
	<family>fixed</family>
	<prefer>
		<family>console</family>
		<family>Lucida Console</family>
	</prefer>
</alias>

does not work - because fontconfig - in prepending the family console etc in 
front on family fixed in the search pattern chooses to do so with a weak 
binding rather than at the same stength as the family it is prefering (I 
think this is a fontconfig functional problem but thats how it is!).

You can achieve what you want with

 <match>
        <test name="family">
                <string>fixed</string>
        </test>
        <edit name="family" mode="prepend" binding="strong">
                <string>console</string>
        </edit>
        <edit name="family" mode="prepend" binding="strong">
                <string>Lucinda Console</string>
        </edit>

</match>


- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+W9T8uFHxcV2FFoIRAtlkAJwO3Jtb60miLz2KH5POo+Nu+2X6AwCfd1pK
61vyFlSQ2cDlqmJQ6FAoN1Q=
=FRJ+
-----END PGP SIGNATURE-----

Message #67 received at 179519-submitter@bugs.debian.org (full text, mbox, reply):

From: Branden Robinson <branden@debian.org>

To: control@bugs.debian.org, 179519-submitter@bugs.debian.org

Subject: Re: Monospaced fonts giving wrong font metrics

Date: Tue, 29 Apr 2003 16:52:45 -0500

[Message part 1 (text/plain, inline)]

retitle 179519 libxft2: monospaced fonts giving wrong font metrics
tag 179519 + moreinfo
thanks

Mr. Chandler,

I have recently taken over the xft2 package from Colin Walters, and in
reviewing this old bug report I must confess to some confusion.

Both fontconfig and XFree86 are getting blamed for various aspects of
the behavior cited in this report, and amidst all the quoted-unprintable
mess this history of this bug is fairly difficult to follow.

Could you reiterate what the specific Xft-related problem is, please, so
that I can attempt to address this report intellgently?

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |      Ignorantia judicis est calamitas
branden@debian.org                 |      innocentis.
http://people.debian.org/~branden/ |

[Message part 2 (application/pgp-signature, inline)]

Message #74 received at 179519-quiet@bugs.debian.org (full text, mbox, reply):

From: Alan Chandler <alan@chandlerfamily.org.uk>

To: Branden Robinson <branden@debian.org>, 179519-quiet@bugs.debian.org

Subject: Re: Bug#179519: Monospaced fonts giving wrong font metrics

Date: Wed, 30 Apr 2003 20:22:36 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 29 Apr 2003 10:52 pm, Branden Robinson wrote:
> retitle 179519 libxft2: monospaced fonts giving wrong font metrics
> tag 179519 + moreinfo
> thanks
>
> Mr. Chandler,
>
> I have recently taken over the xft2 package from Colin Walters, and in
> reviewing this old bug report I must confess to some confusion.
>
> Both fontconfig and XFree86 are getting blamed for various aspects of
> the behavior cited in this report, and amidst all the quoted-unprintable
> mess this history of this bug is fairly difficult to follow.
>
> Could you reiterate what the specific Xft-related problem is, please, so
> that I can attempt to address this report intellgently?


Sure - sorry it got so complicated - but the problem arose as part of a month 
long chase of why konsole fonts were coming out strange - particularly double 
spaced.  This path threw up loads of little niggardly problems some of which 
caused me to raise the above bug report and then report further tracking of 
the problem from libXft through fontconfig and on to libfreetype.

I think the majority of the problems are solved now, although there are one or 
two issues round the outside that might still be outstanding.  Let me try and 
summarise the issues as I now see them.  Given your history as maintainer in 
this area I guess you can make a much better judgement than I can as to what 
is still a problem and what isn't.

1) Issues which I think have been fixed

a) xfonts-konsole package the fonts did not have the correct parameter name 
for "family name" in the font file thus libfreetype was not recognising it
correctly and fc-cache was putting the filename as the family name, thus 
fontconfig was not matching it properly.  This has been changed in kde cvs 
and I believe has filtered down into the current debs.

b) once a) had been fixed I discovered libfreetype had bugs which prevented it 
decoding .gz compressed fonts -thus preventing the "console" family name 
being recognised inside the xfonts-konsole fonts.  Again fc-cache was 
substituting the filename for the family name.  I believe this has also now 
filtered down into the debs (at least for unstable)

2) Issues that I don't know what the status is

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.  I am not sure if this has been fixed - I have seen discussion of the 
problem of the freetype mailing list but I have avoided those fonts as I now 
have found a way using /etc/fonts/local.font files to set up "console" as my 
"konsole" font. (see below).  I still think there is a font metrics issue 
with strange fonts, but I am not sure what it actually is.

3) Issues which I don't think have been fixed - not sure whether they should 
or could be - but over the investigation it made realise what a complex 
business this all is.  It needs someone who understands this whole area at a 
strategic level to comment and whilst I now have some understanding, I don't 
think I am the right individual.

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.  Konsole is
attempting to ask for a monospaced font by asking for family name "fixed".  I 
discusses this with Keith Packard (see point h below) and he said the 
application should use "monospace" as the requested family name.

e) Fontconfig has the concept of strong and weak binding for names and QT uses
strong binding for the family name and weak binding for the the concept of a 
font "hint". It uses the "typewriter" hint in its external API and converts 
that to a weak bound request for monospaced through to libXft. However, there 
does not appear to be a QT font approach which allows a null strong bound 
name (it uses the application default which I think is set automatically as 
Helvetica).  So I am confused as to how QT ever uses the hint it creates.

[I haven't really done anything to chase issues d) or e) on the kde side - the 
bug report is still floating around with at least issue d) in it, but I don't 
know if anyone is looking at it.]

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

/usr/X11R6/lib/X11/fonts/misc/12x13ja.pcf.gz

has family name "fixed" but also has other attributes which distinguish
it from a western font which fontconfig doesn't take in to account.  You
can't install the xserver without xfonts base, so you cannot prevent this
font from being installed. [I never discovered why the fontconfig matching 
algorithmn always found this font first - I assumed it was a combination of 
font size needed for my 1024x768 screen resolution combined with the font 
size being asked for by konsole (13pt I think - although from the note I left 
on the kde bug report says it seems to be searching for a 9point 100dpi font 
- - its too long ago for me to remember) and the search order that fontconfig 
made in the <dir> entries from /etc/fonts/fonts.conf]. 

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.

h)  Fontcontcong binding problem with <alias> and <prefer> directives in that 
they always create a "weak" binding - so that when matching thus

<alias>
        <family>fixed</family>
        <prefer>
                <family>Console</family>
        </prefer>
</alias>

The fact that the search request was a strong bind to fixed meant that this 
didn't work.  I discussed this with Keith Packard on the fontconfig mailing 
list and he was reluctant to change it and suggested I do

<match>
        <test name="family">
                <string>fixed</string>
        </test>
        <edit name="family" mode="assign" binding="strong">
                <string>console</string>
        </edit>
</match>

which is what I now do.  [I have seen some recent fonts.conf with this in them
        <match target="pattern">
                <test name="prefer_outline">
                        <bool>true</bool>
                </test>
                <test name="family">
                        <string>Helvetica</string>
                </test>
                <edit name="family" mode="prepend" binding="same">
                        <string>Arial</string>
                </edit>
        </match>
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]

- -- 
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sCJ/uFHxcV2FFoIRAjhnAJ9lEcuz6Vau4MVwzZo3oCUWwCAAaQCbBxwq
ZKokAEC5i6m4gyQPmQBzZ9w=
=9txX
-----END PGP SIGNATURE-----

Message #79 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Branden Robinson <branden@debian.org>

To: Alan Chandler <alan@chandlerfamily.org.uk>

Cc: 179519@bugs.debian.org

Subject: Re: Bug#179519: Monospaced fonts giving wrong font metrics

Date: Wed, 30 Apr 2003 16:48:52 -0500

[Message part 1 (text/plain, inline)]

On Wed, Apr 30, 2003 at 08:22:36PM +0100, Alan Chandler wrote:
[snip]

Thanks a lot for this exhaustive analysis.  I'll address these
point-by-point.

> 1) Issues which I think have been fixed
> 
> a) xfonts-konsole package the fonts did not have the correct parameter name 
> for "family name" in the font file thus libfreetype was not recognising it
> correctly and fc-cache was putting the filename as the family name, thus 
> fontconfig was not matching it properly.  This has been changed in kde cvs 
> and I believe has filtered down into the current debs.

Okay; if it hasn't, please file a bug against xfonts-konsole.

> b) once a) had been fixed I discovered libfreetype had bugs which prevented it 
> decoding .gz compressed fonts -thus preventing the "console" family name 
> being recognised inside the xfonts-konsole fonts.  Again fc-cache was 
> substituting the filename for the family name.  I believe this has also now 
> filtered down into the debs (at least for unstable)

Okay; if it hasn't please file a bug against fontconfig.

> 2) Issues that I don't know what the status is
> 
> 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.  I am not sure if this has been fixed - I have seen discussion of the 
> problem of the freetype mailing list but I have avoided those fonts as I now 
> have found a way using /etc/fonts/local.font files to set up "console" as my 
> "konsole" font. (see below).  I still think there is a font metrics issue 
> with strange fonts, but I am not sure what it actually is.

Well, until you're willing or able to reproduce this problem, there's
probably not a lot can be done.  However, you've done a lot of work
already and if you don't have the energy, I understand.  Someone else
will likely encounter the problem.

> 3) Issues which I don't think have been fixed - not sure whether they should 
> or could be - but over the investigation it made realise what a complex 
> business this all is.  It needs someone who understands this whole area at a 
> strategic level to comment and whilst I now have some understanding, I don't 
> think I am the right individual.
> 
> 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.  Konsole is
> attempting to ask for a monospaced font by asking for family name "fixed".  I 
> discusses this with Keith Packard (see point h below) and he said the 
> application should use "monospace" as the requested family name.

You may wish to file a bug against konsole and/or libqt3c102-mt about
this.  Be sure and quote Keith's mail.

> e) Fontconfig has the concept of strong and weak binding for names and QT uses
> strong binding for the family name and weak binding for the the concept of a 
> font "hint". It uses the "typewriter" hint in its external API and converts 
> that to a weak bound request for monospaced through to libXft. However, there 
> does not appear to be a QT font approach which allows a null strong bound 
> name (it uses the application default which I think is set automatically as 
> Helvetica).  So I am confused as to how QT ever uses the hint it creates.
> 
> [I haven't really done anything to chase issues d) or e) on the kde side - the 
> bug report is still floating around with at least issue d) in it, but I don't 
> know if anyone is looking at it.]

I think this issue should probably be raised on the fontconfig
discussion list.

> f) Fontconfig is matching family name "fixed" with a Japanese font from
> within xfonts-base.  This is because the font 
> 
> /usr/X11R6/lib/X11/fonts/misc/12x13ja.pcf.gz
> 
> has family name "fixed" but also has other attributes which distinguish
> it from a western font which fontconfig doesn't take in to account.  You
> can't install the xserver without xfonts base,

Not strictly true; see <http://people.debian.org/~branden/xsf/FAQ>.

> so you cannot prevent this font from being installed. [I never
> discovered why the fontconfig matching algorithmn always found this
> font first - I assumed it was a combination of font size needed for my
> 1024x768 screen resolution combined with the font size being asked for
> by konsole (13pt I think - although from the note I left on the kde
> bug report says it seems to be searching for a 9point 100dpi font - -
> its too long ago for me to remember) and the search order that
> fontconfig made in the <dir> entries from /etc/fonts/fonts.conf]. 

Fontconfig's preference for 12x13ja.pcf.gz over 6x13.pcf.gz is another
issue that should perhaps be raised on the fontconfig discussion list.

> 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.

As above, see the FAQ.  However, it may be a good idea for the X server
to be configurable to not treat this as a fatal error as the core font
mechanism becomes more and more deprecated.

> h)  Fontcontcong binding problem with <alias> and <prefer> directives in that 
> they always create a "weak" binding - so that when matching thus
> 
> <alias>
>         <family>fixed</family>
>         <prefer>
>                 <family>Console</family>
>         </prefer>
> </alias>
> 
> The fact that the search request was a strong bind to fixed meant that this 
> didn't work.  I discussed this with Keith Packard on the fontconfig mailing 
> list and he was reluctant to change it and suggested I do
> 
> <match>
>         <test name="family">
>                 <string>fixed</string>
>         </test>
>         <edit name="family" mode="assign" binding="strong">
>                 <string>console</string>
>         </edit>
> </match>
> 
> which is what I now do.  [I have seen some recent fonts.conf with this in them
>         <match target="pattern">
>                 <test name="prefer_outline">
>                         <bool>true</bool>
>                 </test>
>                 <test name="family">
>                         <string>Helvetica</string>
>                 </test>
>                 <edit name="family" mode="prepend" binding="same">
>                         <string>Arial</string>
>                 </edit>
>         </match>
> 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]

I'm not confident to address this, but it's clearly a fontconfig issue.

I have reassigned this report to libfontconfig1, but as you note, this
is really at least 8 different issues.

Thanks for your patience and thorough analysis.

-- 
G. Branden Robinson                |
Debian GNU/Linux                   |      If encryption is outlawed, only
branden@debian.org                 |      outlaws will @goH7Ok=<q4fDj]Kz?.
http://people.debian.org/~branden/ |

[Message part 2 (application/pgp-signature, inline)]

Message #84 received at 179519@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: 179519@bugs.debian.org

Cc: Keith Packard <keithp@keithp.com>

Subject: Re: Bug#179519: Monospaced fonts giving wrong font metrics

Date: Wed, 09 Mar 2005 18:37:32 -0800

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Message #89 received at 179519-close@bugs.debian.org (full text, mbox, reply):

From: Aron Xu <happyaron.xu@gmail.com>

To: 179519-close@bugs.debian.org

Subject: Re: Bug #179519: libxft2: monospaced fonts giving wrong font metrics

Date: Sun, 10 Jul 2011 23:14:19 +0800

Ancient bug in 2003, and the problems mentioned has been already
addressed (at least I don't see any of them still appear now). Closing.


-- 
Regards,
Aron Xu

Send a report that this bug log contains spam.