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.
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.
Created attachment 37 [details]
FC_DEBUG=3 log for qfd (font displayer from Qt examples) 19M ungzipped
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).
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...
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 email@example.com 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 ;->
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
I drop this note for 3rd party readers who might be interested in their 2 coins in this
Any new encoding support belongs in fontconfig.
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.