| Summary: | Problem rendering bold font... | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | fabrice <fabriceperrinel> |
| Component: | Text | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | ddkilzer, hyatt, webkit |
| Priority: | P2 | ||
| Version: | 420+ | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
| URL: | http://www.hand-coding.com/webkit/rendering_bug.html | ||
|
Description
fabrice
2007-02-06 09:56:01 PST
This is the Google double-bold issue. Fixed by Bug 6146. *** This bug has been marked as a duplicate of 6146 *** But how can it be fixed if it still reproduces? (In reply to comment #2) > But how can it be fixed if it still reproduces? Between the URL (http://www.hand-coding.com/webkit/rendering_bug.html) and the statement, "I wasn't be able to write a page to make this happen...", I thought Fabrice was looking at someone else's site (which only had screenshots--no actual HTML to reproduce the issue) and trying to write a test for it himself but couldn't get it to reproduce. (Looking back, I guess that wouldn't make much sense, would it? :) Fabrice, does this still happen on Google for you? If so could you provide a URL to a Google page where this happens? Usually it's easier to start with a page that's displaying the issue, then reduce it by removing parts of the page until the minimum is left that still shows the bug. Also, what version of Safari were you using? Hi, the URL http://www.hand-coding.com/webkit/rendering_bug.html actually points to my own website. I made the screenshots for you as an example. I still experience the bug on any Google's result page, but also on macupdate.com, any product page (and not only Google ads); I added the MacUpdate screenshot to the url above. "I wasn't be able to write a page to make this happen..." means I can't write the "correct" html code to make the thing appear... Will try again... I use rev 19418. Forgot to mention that this bug is recent. I do not try each webkit build (may be one out of ten? Frankly I don't know) but I'm pretty sure that this bug wasn't here some times ago... -Fabrice Does this page show the issue for you? I don't see any problems with it using a local debug build of WebKit r19434 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037): http://www.google.com/search?hl=en&q=safari&btnG=Google+Search I don't see the double-bold on this page, either: http://www.google.fr/search?hl=fr&q=safari&btnG=Rechercher&meta= I'm just really confused now... 1) David, how do you use build 19434 while nightly.webkit.org says i'm up to date with build 19418 ? :) 2) This bug (12633) has been marked as a duplicate of bug 6146, but I just realized that this bug was closed nearly one year ago!!! Come on! I use Google search hundred times per day! This bug showed up for me just few days ago ('till I decided to open this thread). Also I use MS Office 2004 since er... 2004? My first bug report was about a bug with Drosera. This bug was solved in build 18849 and I'm sure the double-bold bug wasn't here for me at this time. So I downloaded build 18849 again few minutes ago and the bug showed up. It means I put some bad Arial suitcase in the meantime, right? Because I can confirm that the code "<body style="font-family:arial"><b>This is too bold</b></body>" bring the bug just like a satanic incantation... :) -Fabrice (In reply to comment #8) > 1) David, how do you use build 19434 while nightly.webkit.org says i'm up to > date with build 19418 ? :) I check out the source code and build it myself. :) You must have Xcode installed (and Apple's development tools) to do this, though. http://webkit.org/building/checkout.html > 2) This bug (12633) has been marked as a duplicate of bug 6146, but I just > realized that this bug was closed nearly one year ago!!! > Come on! I use Google search hundred times per day! This bug showed up for me > just few days ago ('till I decided to open this thread). Also I use MS Office > 2004 since er... 2004? > > My first bug report was about a bug with Drosera. This bug was solved in build > 18849 and I'm sure the double-bold bug wasn't here for me at this time. So I > downloaded build 18849 again few minutes ago and the bug showed up. > It means I put some bad Arial suitcase in the meantime, right? > Because I can confirm that the code "<body style="font-family:arial"><b>This is > too bold</b></body>" bring the bug just like a satanic incantation... :) It sounds like this is related to specific fonts you have installed on your system. I'm sure there are people that would be interested to know what fonts you have installed and what is causing this issue. Does Font Book or the System Profiler have an export feature that describes all of the fonts installed? Do you know which font is causing the issue, and does removing it fix the issue? "Mid-air collision detected!" ahah :) Well, here's where I am about: Using Linotype FontExplorer I deactivated the thre Arial suitcases found activated. One found in Users/me/Library/Fonts One in HD/Library/Fonts And one on another HD (inside the MacOs 9 System Folder/Fonts). After reboot, it appeared that I wasn't able to activate the MacOs 9 Arial suitcase anymore using FontExplorer (no message, just nothing). So I just activated the one from HD/Library/Fonts and there is no double-bold bug anymore. Chances are the MacOs 9 font came with a QuickTime 6 installer I got some times ago to play an old game but I'm not sure. Anyway it works ; the Arial version is 2.90. Still I'm not sure if the font is guilty at all or if webkit just doesn't stand it since a given date. Thanks -Fabrice The Mac OS 9 font shouldn't affect fonts in OS X at all. I'm curious if you re-enable the Arial font in /Users/me/Library/Fonts whether the issue returns. Do you know where you got that Arial font (suitcase)? I re-enabled the Arial font in /Users/me/Library/Fonts and rebooted to no change. However, the more I look at all that, the less it's clear for me : Could you have a look at this screenshot again please? http://www.hand-coding.com/webkit/rendering_bug.html It was taken before I removed the MacOs 9 Arial font. This is the corresponding live url at MacUpdate : http://www.macupdate.com/info.php/id/10905 1) Do you see the bold-blurred column to the right (Badia Software, 976, etc...) ? The fonts specified in the stylesheet are "geneva,verdana,lucida console,arial,helvetica,sans-serif" for the blue links and "ms sans serif, Arial, Geneva, Verdana" for the grey text and the "Quark" links bellow. As I don't have "ms sans serif", the grey text is rendered with arial, so the bug. You can notice that the blue links (geneva) are a bit spooky too... Now, I've removed the old arial font so the grey text is perfect and the blue links still spooky. 2) Strangely enough, the regular webkit doesn't render the blue links with the spooky geneva bold but with a nice and sharp verdana bold instead (???), while the mozilla engine render the correct geneva bold but sharper... What do you think? -Fabrice (In reply to comment #12) > What do you think? I'm not really a font expert--I was just trying to get you to determine the cause of the problem so that it's reproducible by others. :) I was hoping some font experts would chime in. Did you copy the Mac OS 9 Arial font and install it in an OS X font folder? Is that was causes the issue? (In reply to comment #13) > Did you copy the Mac OS 9 Arial font and install it in an OS X font folder? Is > that was causes the issue? > No, as said above : "One found in Users/me/Library/Fonts One in HD/Library/Fonts And one on another HD (inside the MacOs 9 System Folder/Fonts)." For whatever reason, I found the OS 9 font activated this morning, and the bug...Arg! So I deactivated it again and removed it from its OS 9 system folder. The bug disapeared instantly, even without a reboot. Now, about the geneva thing, have a look at this : <p style="font-family:geneva,verdana,arial">I uppercase normal <b>I uppercase bold</b></p> Webkit correctly uses the geneva font to render the text. The bold part is a bit ugly though. Now, Safari with the regular webkit renders the "normal" part in geneva but clearly uses verdana to render the bold part. If I remove verdana from the stylsheet, it will use arial, skipping geneva in all cases...Why? From my point of view, this explains the overall sharper rendering in Safari over webkit when using sans-serif bold fonts. -Fabrice (In reply to comment #14) > No, as said above : > "One found in Users/me/Library/Fonts > One in HD/Library/Fonts > And one on another HD (inside the MacOs 9 System Folder/Fonts)." > > For whatever reason, I found the OS 9 font activated this morning, and the > bug...Arg! > So I deactivated it again and removed it from its OS 9 system folder. The bug > disapeared instantly, even without a reboot. Weird! Is the OS 9 font folder somehow set up in the "font search path" for OS X (assuming there is such a thing)? > Now, about the geneva thing, have a look at this : > <p style="font-family:geneva,verdana,arial">I uppercase normal <b>I uppercase > bold</b></p> > > Webkit correctly uses the geneva font to render the text. The bold part is a > bit ugly though. > Now, Safari with the regular webkit renders the "normal" part in geneva but > clearly uses verdana to render the bold part. If I remove verdana from the > stylsheet, it will use arial, skipping geneva in all cases...Why? > From my point of view, this explains the overall sharper rendering in Safari > over webkit when using sans-serif bold fonts. I don't see the Verdana font in bold with the above example. Do you have a copy of Geneva in the OS 9 folder as well? If so, perhaps removing that font from that folder will fix this issue as well. BTW, this tool is really handy for viewing HTML snippets and changing them live: http://software.hixie.ch/utilities/js/live-dom-viewer/ (In reply to comment #15) > Weird! Is the OS 9 font folder somehow set up in the "font search path" for OS > X (assuming there is such a thing)? > I don't know ; I will have a look at this later... > I don't see the Verdana font in bold with the above example. Do you have a > copy of Geneva in the OS 9 folder as well? If so, perhaps removing that font > from that folder will fix this issue as well. > No, there is just one geneva font, located in HD/System/Library/Fonts and the regular Safari webkit refuses to use it in bold (even when no other alternative is specified ; Safari will fall with arial...) You can see it in action here (image + html) : http://www.hand-coding.com/webkit/testcase1.html All that said, I'm not sure if the strange behaviour I see is worth the time you spend on it... Maybe we could just keep in mind that something still have to be clarified in the way webkit deals with fonts... -Fabrice (In reply to comment #16) > All that said, I'm not sure if the strange behaviour I see is worth the time > you spend on it... > Maybe we could just keep in mind that something still have to be clarified in > the way webkit deals with fonts... The Geneva issue only appears in shipping Safari, but not in WebKit. That's good news! That means this bug is fixed in WebKit. The only remaining issue, then, is how to reproduce the Arial double-bold rendering. It sounds like adding/activating the OS 9 Arial font causes this, correct? (In reply to comment #17) > The Geneva issue only appears in shipping Safari, but not in WebKit. That's > good news! That means this bug is fixed in WebKit. > > The only remaining issue, then, is how to reproduce the Arial double-bold > rendering. It sounds like adding/activating the OS 9 Arial font causes this, > correct? > Correct. Unfortunately I try for two or three hours to reproduce the bug without success. It seems that I'm not be able to permanently reactivate this bloody Os 9 font. I tried to clean the sys font cache and all these things you can think about with no result. What I can say for now is : 1) When the bug occured, all the three arial suitcases was activated at the same time, including the Classic one. 2) The bug doesn't occur when the classic font is the only one to be activated nor if I move it to one of the OsX font folder. 3) The only thing I noticed about this font is that Linotype FontExplorer lists its components in a different order (that is : "Arial Bold Italic, Arial Bold, Arial Italic, Arial" instead of "Arial, Arial Bold, Arial Bold Italic, Arial Italic"). The idea was to run a test with a pre "-webkit-text-fill", "-webkit-text-stroke" build, but it makes no sense since I can't reproduce the bug right now... Tired... -Fabrice Per comment #16 and #17 I close this bug as fixed. I addition the test case URL is dead. Fabrice, would it be possible to attach the test case to this bug? Does it still occur? |