Bug 99323

Summary: Fonts have gone bold again in Gnome
Product: [Retired] Red Hat Raw Hide Reporter: Trever Adams <trever>
Component: ghostscript-fontsAssignee: Owen Taylor <otaylor>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: mharris, rdieter, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-09 19:12:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 100643    
Attachments:
Description Flags
Examples of bold missing
none
Showing it as fixed
none
Showing problem in fedora core devel none

Description Trever Adams 2003-07-17 17:33:22 UTC
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):
XFree86-4.3.0-17

How reproducible:
Always

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
and non-bold.

Additional info:

Comment 3 Owen Taylor 2003-07-28 17:07:50 UTC
Is this *all* fonts, or just your serif fonts, as in your web 
browser.

(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)


Comment 4 Trever Adams 2003-07-28 18:31:51 UTC
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).

Comment 5 Owen Taylor 2003-07-28 18:38:49 UTC
I'd need a screenshot to say anything further.


Comment 6 Trever Adams 2003-07-28 18:41:05 UTC
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
the bug.

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.

Comment 7 Owen Taylor 2003-07-28 18:59:15 UTC
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
component.

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.


Comment 8 Miloš Komarčević 2003-08-06 12:57:12 UTC
I think this might be a duplicate of

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97683

There are still some problems with urw-fonts as noted.

Comment 9 Owen Taylor 2003-08-07 14:17:40 UTC
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.


Comment 10 Trever Adams 2003-08-07 16:15:20 UTC
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.

Comment 11 Owen Taylor 2003-08-07 16:24:14 UTC
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.



Comment 12 Trever Adams 2003-08-21 16:23:05 UTC
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:

XFree86-100dpi-fonts-4.3.0-21
XFree86-4.3.0-21
XFree86-75dpi-fonts-4.3.0-21
XFree86-base-fonts-4.3.0-21
XFree86-devel-4.3.0-21
XFree86-font-utils-4.3.0-21
XFree86-libs-4.3.0-21
XFree86-libs-data-4.3.0-21
XFree86-Mesa-libGL-4.3.0-21
XFree86-Mesa-libGLU-4.3.0-21
XFree86-tools-4.3.0-21
XFree86-truetype-fonts-4.3.0-21
XFree86-xauth-4.3.0-21
XFree86-xdm-4.3.0-21
XFree86-xfs-4.3.0-21


(Remember, both no bold and too much bold happen at least once every beta
cycle... why?!?)

Comment 13 Trever Adams 2003-08-21 16:26:04 UTC
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
trustworthy.

Comment 14 Owen Taylor 2003-08-21 16:31:36 UTC
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.



Comment 15 Trever Adams 2003-08-21 16:42:55 UTC
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
RedHat.

Why 10 instead of 12 or 14... because 12 and 14 are big and ugly.

Comment 16 Trever Adams 2003-08-25 05:39:19 UTC
The below set of packages seems to have fixed the problem.  Partial screen shot
to be added momentarily.

XFree86-100dpi-fonts-4.3.0-22
XFree86-4.3.0-22
XFree86-75dpi-fonts-4.3.0-22
XFree86-base-fonts-4.3.0-22
XFree86-devel-4.3.0-22
XFree86-font-utils-4.3.0-22
XFree86-libs-4.3.0-22
XFree86-libs-data-4.3.0-22
XFree86-Mesa-libGL-4.3.0-22
XFree86-Mesa-libGLU-4.3.0-22
XFree86-tools-4.3.0-22
XFree86-truetype-fonts-4.3.0-22
XFree86-xauth-4.3.0-22
XFree86-xdm-4.3.0-22
XFree86-xfs-4.3.0-22


Comment 17 Trever Adams 2003-08-25 05:41:15 UTC
Created attachment 93888 [details]
Showing it as fixed

Comment 18 Trever Adams 2003-08-25 05:42:44 UTC
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
than that?

What is different between -21 and -22 of these packages?

Comment 19 Owen Taylor 2003-08-29 15:19:45 UTC
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.

Comment 20 Mike A. Harris 2003-08-30 09:53:29 UTC
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 <mharris> 4.3.0-22
[SNIP]
- 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 <mharris> 4.3.0-21
[SNIP]
- 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...

Comment 21 Trever Adams 2003-09-02 19:46:41 UTC
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.

Comment 22 Trever Adams 2004-01-20 17:39:10 UTC
The problem is definitely back in Fedora Core development.  I just
updated these packages:

file-4.07-1
gedit-2.4.0-5
ghostscript-7.07-17
ghostscript-fonts-8.11-1
gnome-mime-data-2.4.1-1
httpd-2.0.48-7
httpd-manual-2.0.48-7
hwdata-0.103-1
intltool-0.29-1
mod_ssl-2.0.48-7
openoffice.org-1.1.0-20
openoffice.org-i18n-1.1.0-20
openoffice.org-libs-1.1.0-20
spamassassin-2.62-3
star-1.5a25-3
system-config-printer-0.6.91-1
system-config-printer-gui-0.6.91-1
ypbind-1.16-1
zlib-1.2.1.1-1
zlib-devel-1.2.1.1-1
libgnomecups-0.1.6-2


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
standard now?

Comment 23 Trever Adams 2004-01-20 17:41:05 UTC
Created attachment 97132 [details]
Showing problem in fedora core devel

Notice that the buttons and such are all bold?

Comment 24 Trever Adams 2004-01-20 17:42:23 UTC
Where is fedora-core-devel in the version list?

Changing target/problem platform.

Comment 25 Mike A. Harris 2004-01-22 07:46:03 UTC
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.

Comment 26 Trever Adams 2004-01-22 20:18:57 UTC
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
indeed back.

If Serif = Nimbus Roman somehow, then we are probably only talking one
font.

Comment 27 Trever Adams 2004-01-22 20:21:17 UTC
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.

Comment 28 Owen Taylor 2004-01-22 21:19:04 UTC
What changed in the new ghostscript-fonts? If it adds the URW
fonts, then they need to be removed in packaging.

Comment 29 Trever Adams 2004-01-22 21:27:34 UTC
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.

Comment 30 Owen Taylor 2004-01-22 21:34:06 UTC
Sorry, that question was directed at Tim Waugh, who I added
to the cc:; I think he upgraded ghostscript-fonts recently.


Comment 31 Tim Waugh 2004-01-22 22:43:38 UTC
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?

Comment 32 Tim Waugh 2004-01-22 23:10:38 UTC
Never mind, I've reverted to 5.50.  The 8.11 tarball is no good.