Summary: | REGRESSION - Bookmark Bar text rendering changed | ||
---|---|---|---|
Product: | WebKit | Reporter: | Gibbons Burke <gibbonsb> |
Component: | New Bugs | Assignee: | mitz |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | darin, mitz |
Priority: | P1 | Keywords: | Regression |
Version: | 523.x (Safari 3) | ||
Hardware: | Mac | ||
OS: | OS X 10.4 | ||
Attachments: |
Description
Gibbons Burke
2007-05-14 08:09:41 PDT
Created attachment 14548 [details]
Screen capture comparing bookmark bars in Safari.app and Webkit.app
In this image the controls for Safari are on top and Webkit.app on the bottom. Note how 'smudged' and out of focus the text appears in WebKit.app, especially on the special characters which have fine detail.
Created attachment 14549 [details] Replaces Attachment 14548 [details] - Updated screen capture - PNG - better resolution This higher resolution PNG image shows better the difference between how Safari.app and WebKit.app render the characters in the Bookmarks Bar. The WebKit regression 'smudges' the text and obscures details in the character forms. Looks like synthetic bold, which shouldn't be done for chrome. Created attachment 14552 [details]
Avoid synthetic bold and italic in the chrome
Comment on attachment 14552 [details]
Avoid synthetic bold and italic in the chrome
r=me
I think I was a little hasty reviewing this. It's true that the chrome should not have synthetic bold, but I don't think the platform font code path really needs a flag to tell it not to synthesize bold. Instead, I think we should not have synthesized bold because the font is already bold. Or something along those lines. I would like to do a better fix at some point. Or I could be convinced this fix was correct. In any case, it's good to have the correct behavior, even if it might be for the wrong reason. So I don't regret that we landed the change. (In reply to comment #7) > I think we should not > have synthesized bold because the font is already bold. I'm not sure which font "the font" refers to. The platform font was Lucida Grande Bold, which has the bold trait. The fallback font for, e.g., the AQUARIUS character (U+2652) is Apple Symbol Regular, which does not have the bold trait. That's when the font cache decides to use synthetic bold, and that's when the patch says that it shouldn't. > Or I could be convinced this fix was correct. Did I convince you? I think it may have been clearer if the Font had a flag named "do not synthesize missing traits in fallback fonts", but in practice this coincides with "this Font was constructed from a FontPlatformData". (In reply to comment #8) > I think it may have been clearer if the Font had a flag named "do not > synthesize missing traits in fallback fonts", but in practice this coincides > with "this Font was constructed from a FontPlatformData". Yes, I think it's sort of a "coincidence" that we want this behavior in Safari UI, and also happen to use the FontPlatformData code path in that case, so a separate boolean would be clearer. The reason we don't want to synthesize bold has something to do with how Lucida Grande Bold looks and what fallback fonts we typically get. Thanks for explaining. Maybe we should just add a comment to the fallback code -- I don't think any code changes are needed, but the fallback code logic is not self explanatory. Created attachment 14582 [details]
Screen capture showing the side by side QuadCam images
I'm unable to persuade Snapz Pro to save the movie image I capture to disk so this is a still capture. I tried to capture one of the glitch frames but was unable to do so. But one thing to notice is that the WebKit.app window on the left's URL shows the page is still loading. In Safari on the right this isn't an issue.
Comment on attachment 14582 [details]
Screen capture showing the side by side QuadCam images
Apologies -- should be associated with bug
13642
|