-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 26 Jan 2003 4:51 pm, Alan Chandler wrote:> I am not sure that I have found the right place to ask this question. > > A few weeks ago, I installed fontconfig (Debian Unstable), with (I assume - > and thats why I am not sure I am at the right place) libxft2. > > Since then, I have had a strange problem in kde (konsole) with the console > font that it provides (see http://bugs.kde.org/show_bug.cgi?id=52538 )Nobody replied to this posting so I STILL don''t know if I am at the right place.> > I have been trying to debug the problem over the last couple of weeks and > have narrowed it down to the fact that using QT - if I toggle the > FixedPitch property of the font that a piece of text is displayed in the > text display displays normally when the Fixed Pitch attribute is off and > seems to have a double width spacing when the Fixed Pitch attribute is on. > > With a small application doing just that - I have been running a debugger > into the qt code to find why it changes the character spacing.The font family is Helvetica OK - I now can see exactly what is happening. QT looks for a font that matches the characteristics - it is finding a match from Xft both for non Fixed Pitch (XFT_PROPORTIONAL) and Fixed Pitch (XFT_MONO or XFT_CHARCELL) dependent of whether its own fixedPitch flag has been set by the application.> Its > difficult to be sure but I am almost convinced that when it calls the xft > library to render the text it does not know that it will be rendered at > this double width.I am wrong here - and this is the crux of the problem. Individual character widths are found by calling XftTextExtent16. When Helvetica font (default) is found which is XFT_PROPORTIONAL - the individual character widths vary from 4 pixels wide for a space to 9 pixels wide for a ''m''. When the same font is found which has a type of XFT_MONO or XFT_CHARCELL then every character has a width of 12 pixels. This distorts the font and makes it look stretched out, with a large gap between each character. I repeated the test with the "Console" font - which was the subject of my original bug report and is supposidely a fixed pitch font naturally, at it is returning (for point size 12) character widths of 26 pixels. I don''t know if this is considered a bug, or where to report it to. - -- Alan Chandler alan@chandlerfamily.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PXusuFHxcV2FFoIRAnBAAJ9GAYdeNOswudBFh0ki2KMjng7UvwCfWe3N EBayNLqDZPHhbEXuG3tsgPk=ne+u -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 17 Feb 2003 1:00 am, Keith Packard wrote:> Around 18 o''clock on Feb 15, Alan Chandler wrote: > > I need to find how the "font patterns" are set up from the fonts. Can > > someone explain how this works? [In broad terms only, I can delve into > > the right bit of code one I find it] > > Fontconfig uses Freetype2 to extract information from font files. Family > names are the hardest to locate, so fontconfig does quite a bit of work to > find something usable. That code all lives in fcfreetype.c and you can > watch it in action by enabling debugging of the font scanning logic > (export FC_DEBUG=384) before running ''fc-cache -v -f .'' in the directory > containing the relevant fonts.Thanks for that - although from the output it seems that it is finding the directories from /etc/fonts/fonts.conf rather than just running in the directory. What I discovered before your reply, and which the debug output you suggested seems to confirm, is that the family name in the fonts.cache-1 file is created by fc-cache because freetype says that the family name is 0 bytes long. The family name appears to be created based on the filename (console8x16.pcf.gz - which is turned into console8x16.pcf as the family name). I am now discussing on the freetype list why (I think that the font type is not being recognised - maybe something to do with the compressed nature of the file?). Its been a long hard slog to get this far - and I still need to explore why the spacing between the characters is all wrong. Still I will keep going - its fun learning about it all:-) - -- Alan Chandler alan@chandlerfamily.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+UI+7uFHxcV2FFoIRAjkzAJ0QXIfKPo7PO7jBMUxYAcAr5SheQgCfeh2y FaD4C3ZxAj1CAYtGZPi6KaY=scua -----END PGP SIGNATURE-----
Around 18 o''clock on Feb 15, Alan Chandler wrote:> I need to find how the "font patterns" are set up from the fonts. Can someone > explain how this works? [In broad terms only, I can delve into the right bit > of code one I find it]Fontconfig uses Freetype2 to extract information from font files. Family names are the hardest to locate, so fontconfig does quite a bit of work to find something usable. That code all lives in fcfreetype.c and you can watch it in action by enabling debugging of the font scanning logic (export FC_DEBUG=384) before running ''fc-cache -v -f .'' in the directory containing the relevant fonts. -keith
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 02 Feb 2003 8:12 pm, Alan Chandler wrote:> On Sunday 26 Jan 2003 4:51 pm, Alan Chandler wrote: > > I am not sure that I have found the right place to ask this question. > > > > A few weeks ago, I installed fontconfig (Debian Unstable), with (I assume > > - and thats why I am not sure I am at the right place) libxft2. > > > > Since then, I have had a strange problem in kde (konsole) with the > > console font that it provides (see > > http://bugs.kde.org/show_bug.cgi?id=52538 ) > > Nobody replied to this posting so I STILL don''t know if I am at the right > place.AND nobody replied to the second posting either:-( - BUT NOW IT THINK I AM AT THE RIGHT PLACE. I have been digging away some more, and in particular in fcmatch.c to find out what is happening. I think the problem is that this routine is trying to compare font patterns with a priority order of foundary, character set, family (strong), language, family (weak) ... It does not find the console font as an exact match - what appears to happen is that it does find a match with console, but in the fonts pattern there are a number of elements. For the third element font.elt[2]->object = "family" but the font.elt[2]->values->value has a string value of "console8x16.pcf" (and there are no more values attached to family). The verdana font is eventally seen as a closer match although it only matches on the weak family name (I think this has been added to the requesting pattern by fontconfig as a result of a Style request from a high level routine for "sans" [and translated into sans-serif by fontconfig, and then translated [ie replaced in he pattern] to a list of weak matching font names]. The filename in /usr/share/fonts is console8x16.pcf.gz - but if I do a xlsfonts - the family name in these fonts is shown as "console". This differs from what fontconfig finds. I need to find how the "font patterns" are set up from the fonts. Can someone explain how this works? [In broad terms only, I can delve into the right bit of code one I find it] - -- Alan Chandler alan@chandlerfamily.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ToM4uFHxcV2FFoIRAoj+AKCqr7UZWs3dLFfcq2O4bmKDDTIJlQCfRF9o /fewKK5+RQao/u2wbpmGuzU=lz+X -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I am not sure that I have found the right place to ask this question.
A few weeks ago, I installed fontconfig (Debian Unstable), with (I assume -
and thats why I am not sure I am at the right place) libxft2.
Since then, I have had a strange problem in kde (konsole) with the console
font that it provides (see http://bugs.kde.org/show_bug.cgi?id=52538 )
I have been trying to debug the problem over the last couple of weeks and have
narrowed it down to the fact that using QT - if I toggle the FixedPitch
property of the font that a piece of text is displayed in the text display
displays normally when the Fixed Pitch attribute is off and seems to have a
double width spacing when the Fixed Pitch attribute is on.
With a small application doing just that - I have been running a debugger into
the qt code to find why it changes the character spacing. Its difficult to
be sure but I am almost convinced that when it calls the xft library to
render the text it does not know that it will be rendered at this double
width. Clipping Rectange sizes etc seem to be being calculated on the basis
of the correct font metrics. Trouble is, I haven''t manage to discover
how
the Fixed Pitch attribute is propagated down to the xft library - so I
can''t
quite explain everything.
If my suposition is correct, then it is libxft2 that has the fault. Reading
the info at www.fontconfig.org the suggestion is that its using a different
version of the library that xfree.
So - I am reporting it here.
PS - trying to join mailing list but my membership hasn''t come through
yet (is
it moderated?) so maybe a cc to me on a reply would help - thanks.
- --
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+NBIwuFHxcV2FFoIRAnCoAJ9g42MG5tjsRA4d1tkHTJ429n80JACgigaX
MnCYHKDXcKLpdlK/iNpxaCg=Esww
-----END PGP SIGNATURE-----