Red Hat Bugzilla – Bug 99323
Fonts have gone bold again in Gnome
Last modified: 2007-04-18 12:55:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131
Description of problem:
This happened once before. I updated all the font and XFree86 tools today from
rawhide. Now all the gnome fonts show up as bold. Not very pretty for sure.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Update to the latest XFree86 and fonts/fontutils
2. Watch everything go yucky and bold.
Actual Results: Things are all bold. You can see no difference between bold
Is this *all* fonts, or just your serif fonts, as in your web
(If you've changed your gnome-font-properties settings to use
"Nimbus Roman No 9 L" or "Serif" for the UI font, then it
might be all fonts, even if it is the known problem with serif fonts)
I don't know. I didn't change my font preferences at all. It is just set to
Serif and Sanserif. I am guessing this are standard x fonts now that I dig into
it. The problem cleared itself up last week with updates from rawhide.
This happens at least once every rawhide/beta cycle since around RH6. It always
goes away with in a week or two (provided the file gets updated, which it seems to).
I'd need a screenshot to say anything further.
Please, leave this bug open. I am not sure how to duplicate it since the
packages that caused it are gone from the rawhide list. I would need the font
packages, freetype, X, etc. packages from the last few days before I reported
It isn't just the web browser. It is most striking with the clock. It gets
bold and big. The gnome-menu does the same thing.
I can't leave a bug open unless I have information that I can
use to resolve the bug, or even reassign it the appropriate
if I can *see* the screenshot, I might be able to tell if it's
a duplicate of other bugs, or exactly what the problem is. As
it is currently, there's nothing I can do about it.
If you add more information (in particular, a screenshot), please
reopen the bug from NEEDINFO.
I think this might be a duplicate of
There are still some problems with urw-fonts as noted.
It doesn't sound like the urw-fonts problem from the description, but
without the requested screenshot, I just can't even begin to guess.
As I said, without having the rpms from the time specified, I can't roll back
and show you a screenshot. However, I can show you a few from
mozilla/galeon/whatever that show wobbly baslines (sentence goes up and down
with nearly every letter). But that wasn't what this bug was about.
Wobbly baselines are the urw-fonts problem (fixed in the current rpms),
and not related.
Looks like there's nothing more that can be done on this bug; marking
WORKSFORME since apparently it doesn't occur with current packages.
Ok, I should have mentioned that at times, bold disappears. Some times it is
over emphasized. Today's XFree86 packages have the problem of no bold (or
underemphasized at least). Screenshot included, package versions as follows:
(Remember, both no bold and too much bold happen at least once every beta
Created attachment 93819 [details]
Examples of bold missing
Well, in case you aren't familiar with evolution, Inbox and Virus Collection (I
help out with clamav so I collect viruses to test clamav against) should be in
bold because they contain new messages.
For any nuts who are going to ask, no I won't share my viruses, no I won't
trade them. I don't want to end up in jail because some nut wasn't
The screenshot there shows an a non-standard font configuration.
(Or possibly the fonts for an unusual choice of language).
I need to have the information about what language you are running
in and any information about what fonts you are using in order to
be able to evaluate the situation.
It seems to me to be unrelated to this bug report as well, but I'll
leave this open for the moment until you provide more information.
Well, my system is a standard US English setup. According to the gnome font
preference, App is Serif, Desktop is Sans, Window title is Serif Terminal is
Monospace. All size 10, best shapes at 72 dpi. RGB order. Well, it may be
unrelated, but both of these are problems I have frequently in rawhide/beta and
sometimes in errata updates. The font settings are the ones I have used for a
long time, and once the fonts themselves (though not size) were the default from
Why 10 instead of 12 or 14... because 12 and 14 are big and ugly.
The below set of packages seems to have fixed the problem. Partial screen shot
to be added momentarily.
Created attachment 93888 [details]
Showing it as fixed
So, the question is why does this show up as no bold and everything bold at
least once each every development cycle (beta/rawhide) and usually many more
What is different between -21 and -22 of these packages?
It's nothing to do with XFree86. Packages that are involved in drawing
text in GTK+ applications include:
- FreeType (the text rendering engine)
- urw-fonts (the package containing our default serif font)
- fontconfig (the font selection library)
- Pango (the text layout library used by GTK+)
To my knowledge, none of these changed between 8-21 and 8-25 in
a relevant way (a new version of Pango, but nothing in the font
selection algorithm changed.)
Anyways, it's unrelated to this bug report, which is about a particular
problem with urw-fonts which has been fixed.
If your problem re-occurs, could you file a new bug giving the exact
version of the above packages? Thanks.
owen) You forgot about Xft/Xrender being upgraded. XFree86-4.3.0-21 added
the new Xft/Xrender code, and 4.3.0-22 disabled it due to the build problems
I was having. These changes occured roughly within the timeframe indicated
in this bug report:
* Thu Aug 21 2003 Mike A. Harris <firstname.lastname@example.org> 4.3.0-22
- Disabled the new Xft and Xrender code by toggling with_new_xft_and_xrender,
because of an unexplainable build failure that has started occuring only in
the Red Hat buildsystem, which I can't reproduce locally. 4.3.0-21 built
perfectly fine in beehive, but the current rpm fails when compiling the new
Xft, saying that ld can't find -lXrender. I've absolutely no clue why this
is occuring, all of the builds compile both on x86 and AMD64 locally here,
and am unable to debug it on the systems it occurs on in the buildsystem.
* Tue Aug 19 2003 Mike A. Harris <email@example.com> 4.3.0-21
- Integrated Keith Packard's upstream Xft-2.1.2 and Xrender-0.8.3 bugfix
packages from fontconfig.org into XFree86 4.3.0. This fixes a variety of
Xft/Xrender bugs scattered throughout bugzilla against many GNOME and other
applications, etc. (#99468, 99469)
No idea if this may be related to the problem or not, however until the
Xft/Xrender build problem is resolved, it's hard to say. The current
XFree86 4.3.0-22.1 package has Xft/Xrender back again now though, so
if he upgrades to that and the problem returns, then we might be able
to conclude that Xft/Xrender is related. Wether it is a bug or not however
is another question...
Upgraded to the -24 of XFree86 et al. Things are fine. So, I guess this was
that bug and it has been fixed or else I just have a system that is screwy.
The problem is definitely back in Fedora Core development. I just
updated these packages:
The only one I can see as being part of the problem is ghostscript.
However, I didn't know X could use those fonts.
See my font configuration way above. If this is nonstandard what is
Created attachment 97132 [details]
Showing problem in fedora core devel
Notice that the buttons and such are all bold?
Where is fedora-core-devel in the version list?
Changing target/problem platform.
Nothing in XFree86 related to fonts/font rendering has changed in
quite a long time now. Not sure what problem is being experienced
here, but on a hunch, I would suspect font configuration/installation
more than anything. Installing new fonts can override some defaults
and cause things to look differently.
Just a thought.
It is only affecting the ghostscript-fonts package. If I downgrade to
5.50-9 from ghostscript-fonts-8.11-1 the bold in Nimbus Roman (can't
check the serif in font-prefs because my menus are all screwed due to
Fedora Core devel problem).
I have been looking closely at this and I don't believe it is an X
problem. I am starting to believe that something is changing in the
font package itself. Nimbus sans doesn't seem to have this problem.
I don't think Nimbus mono did either.
Abiword doesn't show the problem, Openoffice, gnome-panel
(particularly the clock applet and the menu) do show this. I just
reupdated to the ghostscript-fonts in "rawhide" and the problem is
If Serif = Nimbus Roman somehow, then we are probably only talking one
I forgot to mention, I am not installing new fonts unless
ghostscript-fonts has new fonts between versions. Anyway, as best I
can see it was always the X font packages and ghostscript fonts that
changed when the problem would show up again. I thought that
urw-fonts was the package due to some mistakes I made in trying to
figure out which fonts came from where.
What changed in the new ghostscript-fonts? If it adds the URW
fonts, then they need to be removed in packaging.
I don't know what did. I never said that it contained urw-fonts. I
just said I screwed up in the past in figuring out which package
contained said fonts.
Sorry, that question was directed at Tim Waugh, who I added
to the cc:; I think he upgraded ghostscript-fonts recently.
The ghostscript-fonts package now has the contents of
ghostscript-fonts-std-8.11.tar.gz. What precisely needs removing, or
what precisely should be chosen to be shipped?
Never mind, I've reverted to 5.50. The 8.11 tarball is no good.