Bug 6146

Summary: REGRESSION: Bold font used for Google search result pages is too thick
Product: WebKit Reporter: John Sullivan <sullivan>
Component: Layout and RenderingAssignee: John Sullivan <sullivan>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, fabriceperrinel, mitz
Priority: P2    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
Picture showing a page in 2.0.2 and in tip of tree
none
Here's a copy of the offending font file, zipped
none
Patch that implement's Maciej's idea for a workaround. darin: review+

John Sullivan
Reported 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.
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+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
John Sullivan
Comment 1 2005-12-18 17:08:49 PST
Created attachment 5147 [details] Picture showing a page in 2.0.2 and in tip of tree
John Sullivan
Comment 2 2005-12-18 17:09:39 PST
This is probably happening all over the place, but it caught my eye on Google.
Geoffrey Garen
Comment 3 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.
Darin Adler
Comment 4 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.
John Sullivan
Comment 5 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.
John Sullivan
Comment 6 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.
mitz
Comment 7 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
mitz
Comment 8 2005-12-19 14:05:31 PST
Oops. I didn't mean to post comment #7. Sorry.
John Sullivan
Comment 9 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.
John Sullivan
Comment 10 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.
John Sullivan
Comment 11 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.
John Sullivan
Comment 12 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.
John Sullivan
Comment 13 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.
John Sullivan
Comment 14 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.
John Sullivan
Comment 15 2005-12-20 16:04:30 PST
Created attachment 5194 [details] Patch that implement's Maciej's idea for a workaround.
Darin Adler
Comment 16 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
John Sullivan
Comment 17 2005-12-20 17:16:08 PST
I had removed the extra braces already, but I added another blank line as suggested.
Joost de Valk (AlthA)
Comment 18 2006-01-22 04:52:31 PST
Removing keyword(s) cause bug is closed.
Joost de Valk (AlthA)
Comment 19 2006-01-22 04:55:56 PST
Removing keyword(s) since bug is fixed.
Joost de Valk (AlthA)
Comment 20 2006-01-22 05:00:08 PST
Removing keyword(s) since bug is fixed.
Eric Seidel (no email)
Comment 21 2006-01-31 21:20:38 PST
Removing Regression keyword from bugs already fixed.
David Kilzer (:ddkilzer)
Comment 22 2007-02-06 10:19:09 PST
*** Bug 12633 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.