Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
At the moment, fontconfig (2.2.3) under Gentoo controls both scalable fonts and bitmap fonts. I'm not an expert on all Linux distributions, but at least under Fedora fontconfig only controls the scalable fonts. The behaviour under Gentoo has undesirable consequences: First, the infamous injection of well-known font names like Times or Helvetica into mozilla[-firefox]. If a website explicitly requests Helvetica (http://www.theregister.co.uk is an example), mozilla will use an ugly bitmap version. [Yes, I know it is possible to work this around using /etc/fonts/local.conf] Second, a recently reported slowdown of acroread 7.0.5 at startup (Bug #125253). acroread appears to scan the list of fonts available via fontconfig, and because there are thousands of them under Gentoo, it takes ages. [Note: the latest acroread-7.0.5-r2 ebuild contains at least a partial workaround for this problem] These are two examples that I'm aware of. There are probably more. It is usually possible to work the problems around. But why not simply change the fontconfig to bring it more in line with other distributions, avoiding potential compatibility problems? To me, current behaviour simply seems undesirable, and appears to be impossible to override in a safe manner (/etc/fonts/fonts.conf is not supposed to be modified, and moving font directories around is obviously not a future-proof solution either). In the very least, fontconfig could use the bitmap-fonts USE flag to determine what font directories to use.
The fallback mechanism is just a way to go with the closest matching font, nothing more. If you have no matching font (microsoft fonts or URW), then it needs to look a bit further. You can override such behaviour in most browsers, thats not a task for fontconfig. If you don't want acroread to scan trough the bitmaps, don't install them. The new X modularization makes this much easier. The fact that acroread scans trough them is an acroread bug/choice, nothing that fontconfig should be working around.
Well, I have both Arial from M$ corefonts and Nimbus Sans L from URW installed, and still a bitmap version is chosen for Helvetica. I guess that's because it's an exact name match. Firefox at least respects /etc/fonts/local.conf, so I can override it there. I am told that Konqueror ignores it. How can you override this behaviour in the browsers themselves? (I honestly would like to know) It's a bit of an overkill having to uninstall bitmap fonts, wouldn't you say? I happen to use them in text-intensive apps like xterm and emacs. Sure, you are right that acroread acts stupid, but that's life -- not all apps are perfect. My claim, which might of course be wrong, is that Gentoo is an exception in providing bitmap fonts via fontconfig. Some apps don't expect that and act weird. If providing bitmaps via fontconfig is an exception, perhaps it would be a good idea to evaluate the pros and cons of doing it? In the first place, was that intentional at all? What exactly are the pros?
(In reply to comment #2) > Well, I have both Arial from M$ corefonts and Nimbus Sans L from URW installed, > and still a bitmap version is chosen for Helvetica. I guess that's because > it's an exact name match. Can't reproduce that, give fontconfig 2.3.2 a try there. > Firefox at least respects /etc/fonts/local.conf, so I can override it there. Not sure what you mean, any fontconfig using app has no choice but to respect fontconfigs setup. I > am told that Konqueror ignores it. How can you override this behaviour in the > browsers themselves? (I honestly would like to know) Every browser I know of you can override page suggested fonts, check your preferences pane. Granted, this gives usually a horrible effect, but i guess it's there mainly for a11y/cjk users. > > It's a bit of an overkill having to uninstall bitmap fonts, wouldn't you say? > I happen to use them in text-intensive apps like xterm and emacs. You probably don't use them all, maybe just keep the ones you really use for your console apps. > Sure, you are right that acroread acts stupid, but that's life -- not all apps > are perfect. My claim, which might of course be wrong, is that Gentoo is an > exception in providing bitmap fonts via fontconfig. Some apps don't expect > that and act weird. If providing bitmaps via fontconfig is an exception, > perhaps it would be a good idea to evaluate the pros and cons of doing it? In > the first place, was that intentional at all? What exactly are the pros? I can't speak on behalf of other distro's, but the default config is set so it will cover all fonts provided by X. That means mostly bitmap fonts. I don't think other distro's change that. The problem is not that fontconfig is slow, but that acroread is doing some weird stuff. I really don't see that as something that should be dealt with in fontconfig.
(In reply to comment #3) I tried fontconfig 2.3.2. It's an improvement configuration-wise, as one can at least force bitmap fonts to be unavailable for applications via conf.d/no-bitmaps.conf. So that allows me to work around the problem with webbrowsers, but doesn't help with acroread, which still gets to the bitmap fonts somehow. Also with 2.3.2 by default (i.e. with inactive no-bitmaps) bitmap Helvetica is used in Firefox or Konqueror when browsing http://www.theregister.co.uk/ . Perhaps can't reproduce it because you don't have the bitmap versions in 75dpi and 100dpi? I even edited the fonts.cache file putting the "*dpi" directories at the very bottom, but that didn't change anything. > > Firefox at least respects /etc/fonts/local.conf, so I can override it there. > Not sure what you mean, any fontconfig using app has no choice but to respect > fontconfigs setup. I used to have something like below in my local.conf, I think I found it on Gentoo forums: <match target="pattern" name="family"> <test name="family" qual="any"> <string>Helvetica</string> </test> <edit mode="prepend" name="family"> <string>Arial</string> </edit> </match> This would work with Firefox, but not with Konqueror... > Every browser I know of you can override page suggested fonts, check your > preferences pane. Oh, that's what you meant. Well, sure, that will work, but I would only recommend that to the desperate ones :-). [bitmap fonts] > You probably don't use them all, maybe just keep the ones you really use for > your console apps. I didn't realize that bitmap-fonts flag in xorg-x11 only affects 75dpi and 100dpi fonts, I thought it would get rid of misc as well. Your suggestion might not be that bad after all :-). > I can't speak on behalf of other distro's, but the default config is set so it > will cover all fonts provided by X. Yeah, there is some sense in doing it this way... > I don't think other distro's change that. For the record, I know for sure that Fedora only provides scalable fonts via fontconfig. > The problem is not that fontconfig is slow, but that acroread is doing some > weird stuff. I really don't see that as something that should be dealt with in > fontconfig. Still, fontconfig could help a bit. Even with the latest version, I have the following font directory list: <dir>/usr/share/fonts</dir> <dir>/usr/X11R6/lib/X11/fonts</dir> <dir>/usr/share/fonts</dir> <dir>/usr/local/share/fonts</dir> <dir>/usr/X11R6/lib/X11/fonts/75dpi</dir> <dir>/usr/X11R6/lib/X11/fonts/100dpi</dir> <dir>~/.fonts</dir> The first three entries point to the same directory, and the "*dpi" entries point to subdirectories within that directory. This is just crazy. If I just keep a single /usr/share/fonts there (still with all the bitmaps inside), acroread starts 3 times faster for me...
*** Bug 137039 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > > First, the infamous injection of well-known font names like Times or Helvetica > into mozilla[-firefox]. If a website explicitly requests Helvetica > (http://www.theregister.co.uk is an example), mozilla will use an ugly bitmap > version. [Yes, I know it is possible to work this around using > /etc/fonts/local.conf] In what order did you put your FontPath's in xorg.conf? Did you put the bitmap versions first?
(In reply to comment #6) > > infamous injection of well-known font names like Times or Helvetica > > into mozilla[-firefox]. > In what order did you put your FontPath's in xorg.conf? Did you put the bitmap > versions first? This is irrelevant, because mozilla[-firefox], like any other fontconfig-using app, ignores fonts provided via xorg.conf and uses /etc/fonts/ instead. On top of that, there are no free scalable fonts named Times or Helvetica, so the order of directories does not matter. Putting it differently, bitmap versions will always be "first", simply because there are no alternatives. But, since you asked: my xorg.conf contains directories with bitmap versions first, which seems to be the default behaviour.
> This is irrelevant, because mozilla[-firefox], like any other fontconfig-using > app, ignores fonts provided via xorg.conf and uses /etc/fonts/ instead. Ah, you're right. > I didn't realize that bitmap-fonts flag in xorg-x11 only affects 75dpi and > 100dpi fonts, I thought it would get rid of misc as well. Your suggestion > might not be that bad after all :-). Well, that handy bitmap-fonts flag is gone in modular xorg, so font-adobe-100dpi and font-adobe-75dpi must be installed. foser, do you know why this flag got removed?
No I do not, I think it has to do that a basic X will not function without them and the xorg-x11 package is a meta build for a 'basic X install'. If you want more control over your X install you should be able to install components seperatly. I think the best solution these days is to use a recent fontconfig >=2.3 and enable the no-bitmaps configuration file in /etc/fonts/conf.d .
as foser said, this is now easy to do using the no-bitmaps config. rm /etc/fonts/conf.d/70-yes-bitmaps.conf ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d or use eselect-fontconfig.
