Bug 50 - fonts all look the same
Summary: fonts all look the same
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.1
Hardware: x86 (IA32) FreeBSD
: high enhancement
Assignee: Keith Packard
QA Contact:
URL: http://bugs.kde.org/show_bug.cgi?id=5...
Depends on:
Reported: 2003-03-21 08:11 UTC by Seva Gluschenko
Modified: 2004-12-12 21:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

FC_DEBUG=3 log for qfd (font displayer from Qt examples) 19M ungzipped (15 bytes, application/gzip)
2003-03-25 00:48 UTC, Seva Gluschenko

Description Seva Gluschenko 2003-03-21 08:11:57 UTC
Hi there. 
I'm descending this problem down the lines from KDE where it was shown first. Later 
I've discussed it with Qt heads and last but not least call your attention to the "fonts 
all look the same" problem. 
This generic description needs to be detailed. of course. The URL mentioned refers to 
the originally entered bug. As you can see there, many users experience the same or 
the similar problem. Qt guys didn't have any problem and believe that only 
configuration problem, though. 
Okay, back to details. I use FreeBSD 4-STABLE, XFree86 4.3.0, Qt 3.1.2, KDE 3.1. 
Accordingly, I've tried both Xft-2.1_3 from FreeBSD ports collection and that bundled 
with XFree86 4.3.0 as well, fontconfig the same and 2.1.92, but with no visible changes 
in the issue mentioned. 
As for me, it looks like Xft (or fontconfig?) uses just one font (or mix from several fonts, 
using one font for 12pt and another for 14pt etc) for all of them, so that Helvetica, 
Charter, Times, Schoolbook all look the same. Using qfd from Qt examples, I've 
noticed that fonts are all the same only for cyrillic (koi8-r) encoding and no problems 
with latin-1 symbols. Unfortunately, I don't know whether other submitters experience 
problems with i18n encodings, too or with fonts at all (including ascii symbols). 
Any working solution is appreciated much, because I've been forced to rebuild Qt with 
-no-xft option to have my desktop usable, so Xft isn't used in fact now, but I consider 
such a solution is not scalable and/or upgradeable.
Comment 1 Keith Packard 2003-03-22 09:28:15 UTC
I'm going to need some fontconfig information to help fix this one; we'll need
to know what pattern was presented to the library and what fonts were returned.

If you capture the output from an application run with FC_DEBUG=1 or perhaps
even FC_DEBUG=3, we'll be able to see how fontconfig is behaving.
Comment 2 Seva Gluschenko 2003-03-25 00:48:14 UTC
Created attachment 37 [details]
FC_DEBUG=3 log for qfd (font displayer from Qt examples) 19M ungzipped
Comment 3 Seva Gluschenko 2003-03-25 00:51:56 UTC
I executed qfd with FC_DEBUG=3 environment option set and piped output to the 
attached file. It appeared to be too big, so I gzipped it to 340K file and attached here. 
The first font was Helvetica [Cronyx] 12pt. Then I switched to Row 4 (Cyrillic) and 
started trying fonts. Fixed [Misc] looked different, but then Times [Adobe], Helvetica 
[whatever] and even URW Chancery all look the same. This affects only Row 4 
(Cyrillic), fonts differ in Row 0 (Latin-1). 
Comment 4 Keith Packard 2003-04-19 19:14:57 UTC
Fontconfig selects fonts based on language, and determines language support
based on Unicode coverage for the specified fonts.  It may be that the fonts you
have don't cover enough of the cyrillic alphabet for fontconfig to use them for
documents in koi8-r encoding.

You might try:

$ fc-list :lang=ru family lang

and see what fonts are listed.  Alternatively, you can ask what languages a
particular font supports with:

$ fc-list 'times new roman' family lang

btw -- you managed to attach a file containing the name of the file containing
the log.  I'm not quite sure how that happened...
Comment 5 Seva Gluschenko 2003-04-21 00:43:37 UTC
It's totally disgusting: 
> fc-list :lang=ru family lang | cut -f 1 -d : | sort | uniq 
BTW, a few days ago I've sent a report to fontconfig@fontconfig.org about behaviour 
of fc-cache which caches 0 fonts from cyrillic directories. Maybe they're non-unicode 
and it explains everything, but seems to be not quite acceptable. As long as fontconfig 
is incapable of handling such fonts, Russians are going to stay out of it because of a 
lot of inconvenience caused. 
Regarding the missed attachment - it's strange, sorry for that. I may try to resend you 
by mail directly, I never heard about missed e-mail attachments unless some MIME 
Defang is on the way ;-> 
Comment 6 Seva Gluschenko 2003-05-12 04:42:43 UTC
Well, as Keith figured in our direct conversation, the problem lays in non-Unicode 
cyrillic fonts. He suggested me to correct fonts (that I don't know how to realize). I 
suggested him to add non-Unicode fonts support and make it configurable via 
/etc/fonts/fonts.conf (local.conf). 
I drop this note for 3rd party readers who might be interested in their 2 coins in this 
Comment 7 Bugzilla Administrator 2003-05-16 19:34:03 UTC
Any new encoding support belongs in fontconfig.
Comment 8 Keith Packard 2004-12-13 16:07:40 UTC
I think the right fix here is to create a font->font utility that can
interpolate a Unicode mapping from existing standard encodings.  Moving fonts to
Unicode will eliminate this problem.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.