Bug 6146 - REGRESSION: Bold font used for Google search result pages is too thick
Summary: REGRESSION: Bold font used for Google search result pages is too thick
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: John Sullivan
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-18 17:07 PST by John Sullivan
Modified: 2007-02-06 10:19 PST (History)
3 users (show)

See Also:


Attachments
Picture showing a page in 2.0.2 and in tip of tree (164.56 KB, image/png)
2005-12-18 17:08 PST, John Sullivan
no flags Details
Here's a copy of the offending font file, zipped (198.78 KB, application/zip)
2005-12-20 14:24 PST, John Sullivan
no flags Details
Patch that implement's Maciej's idea for a workaround. (4.37 KB, patch)
2005-12-20 16:04 PST, John Sullivan
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Sullivan 2005-12-18 17:07:45 PST
I just noticed today that the bold font used on Google search result pages is different on tip of tree (as of 
Friday sometime) than in the last released version (Safari 2.0.2, 416.13). It's much thicker and noticeably 
uglier, as if it's being programmatically bolded two times.
Comment 1 John Sullivan 2005-12-18 17:08:49 PST
Created attachment 5147 [details]
Picture showing a page in 2.0.2 and in tip of tree
Comment 2 John Sullivan 2005-12-18 17:09:39 PST
This is probably happening all over the place, but it caught my eye on Google.
Comment 3 Geoffrey Garen 2005-12-18 17:19:23 PST
I think Darin landed some code a while back that bolded fonts that didn't have innate bold representations 
by just drawing them twice, offset by a pixel. That code might be at fault here.
Comment 4 Darin Adler 2005-12-19 12:07:13 PST
This looks like what you'd see if the font were both normal bold and synthetic bold.

I can't reproduce, either.

I suspect a build problem -- make sure this persists after make clean.
Comment 5 John Sullivan 2005-12-19 13:07:13 PST
I can't reproduce on my PowerBook, but I can on my G5. I did a clean build, but the problem persists.
Comment 6 John Sullivan 2005-12-19 13:15:42 PST
Here's a reduction that continues to show the problem on my G5:

<body style="font-family:arial"><b>This is too bold</b></body>

If I change the family name to "times", the problem does not occur.
Comment 7 mitz 2005-12-19 14:03:07 PST
(In reply to comment #6)
> Here's a reduction that continues to show the problem on my G5:
> 
> <body style="font-family:arial"><b>This is too bold</b></body>
> 
> If I change the family name to "times", the problem does not occur.

Do you have Arial
Comment 8 mitz 2005-12-19 14:05:31 PST
Oops. I didn't mean to post comment #7. Sorry.
Comment 9 John Sullivan 2005-12-20 13:33:35 PST
Using my reduction, in -[WebTextRendererFactory fontWithFamilies:traits:size:], the NSFont that's 
returned is:

"Arial-BoldMS 16.00 pt. P [] (0x22c9ef40) fobj=0x222d6580, spc=4.45"

However, [[NSFontManager sharedFontManager] traitsOfFont:font] returns 0.

So this font is visually bold, and its name includes "Bold" (so it's obviously supposed to be bold), but 
NSFontManager doesn't think it's bold. That's why it's getting the syntheticBold bit applied and 
appearing doubly bold.

Maybe this particular font is bad on my machine somehow. I don't know where it came from (installing 
some Microsoft product, presumably). I'll test what happens on my PowerBook in this same code.
Comment 10 John Sullivan 2005-12-20 13:46:57 PST
Nothing obviously different about the font on my PowerBook, at least from po:

"Arial-BoldMS 16.00 pt. P [] (0x0f123590) fobj=0x0f1de320, spc=4.45"

However, here [[NSFontManager sharedFontManager] traitsOfFont:font] returns 0x100000a

I'll have to find the font files on disk and see if they appear different.
Comment 11 John Sullivan 2005-12-20 13:52:13 PST
On my G5 a Spotlight search for "arial" finds 22 fonts; on my Powerbook the same search finds 25 fonts. 
Some of the ones on my G5 show dates in the Spotlight window (in 2000 and 2001), but none of the ones 
on my Powerbook do. Bleah, I say.
Comment 12 John Sullivan 2005-12-20 14:22:04 PST
Alexey Proskuryakov, Mitz Pettel, and others helped look into this. It seems that Microsoft Office X installs 
a version of Arial (2.90) where the bold variant is missing some bit somewhere that NSFontManager uses 
to determine that it's bold. So people who've installed this particular font can run into the problem. Alexey 
could reproduce after installing Arial from Microsoft Office X.

However, my Powerbook has this same version of Arial as the active Arial Bold, and it does not have this 
problem, so there is still some mystery here.

Also, this shows that problems with existing fonts in the field are going to make Safari look bad with our 
new synthetic bold and perhaps italic code.
Comment 13 John Sullivan 2005-12-20 14:24:33 PST
Created attachment 5193 [details]
Here's a copy of the offending font file, zipped

Without zipping first, Safari says the file is empty, presumably because it is
all resource fork.
Comment 14 John Sullivan 2005-12-20 15:50:58 PST
Though the real problems here appear to be in either the font itself or ATS's handling of the font, this 
symptom makes WebKit look bad. I've coded a workaround to avoid this problem, will attach in a moment.
Comment 15 John Sullivan 2005-12-20 16:04:30 PST
Created attachment 5194 [details]
Patch that implement's Maciej's idea for a workaround.
Comment 16 Darin Adler 2005-12-20 17:10:13 PST
Comment on attachment 5194 [details]
Patch that implement's Maciej's idea for a workaround.

Looks good, although that last if statement has braces and shouldn't. I'd also
suggest adding one more blank line or removing a blank line or two inside the
matchedFamily if statement to make the "paragraphing" more even.

r=me
Comment 17 John Sullivan 2005-12-20 17:16:08 PST
I had removed the extra braces already, but I added another blank line as suggested.
Comment 18 Joost de Valk (AlthA) 2006-01-22 04:52:31 PST
Removing keyword(s) cause bug is closed.
Comment 19 Joost de Valk (AlthA) 2006-01-22 04:55:56 PST
Removing keyword(s) since bug is fixed.
Comment 20 Joost de Valk (AlthA) 2006-01-22 05:00:08 PST
Removing keyword(s) since bug is fixed.
Comment 21 Eric Seidel (no email) 2006-01-31 21:20:38 PST
Removing Regression keyword from bugs already fixed.
Comment 22 David Kilzer (:ddkilzer) 2007-02-06 10:19:09 PST
*** Bug 12633 has been marked as a duplicate of this bug. ***