Closed
Bug 589124
Opened 14 years ago
Closed 10 years ago
[D2D] The Archive button in GMail is not the same size/font weight as other buttons when using Direct2D/Write
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: msclrhd, Unassigned)
References
()
Details
(Whiteboard: [country-all])
Attachments
(2 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b4pre) Gecko/20100810 Minefield/4.0b4pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b4pre) Gecko/20100810 Minefield/4.0b4pre Using Direct2D/DirectWrite causes the Archive button to be noticeably bold (different script variant?) and the button to have a larger height than the others. Reproducible: Always Steps to Reproduce: 1. Enable the Direct2D/DirectWrite hardware acceleration 2. Go to the GMail webpage 3. Login to GMail 4. Look at the button strip above the email list view Actual Results: The archive button is 3/4 pixels larger on the top and bottom of the button so it does not match up. It is also noticeably bold. Expected Results: The archive button should have the same height as the other buttons (when Direct2D/DirectWrite is disabled). The boldness of the Archive button does not stand out (if it is actually bold).
Reporter | ||
Updated•14 years ago
|
Summary: The Archive button in GMail is not the same size/font weight as other buttons when using Direct2D/Write → [D2D] The Archive button in GMail is not the same size/font weight as other buttons when using Direct2D/Write
Updated•14 years ago
|
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
I can confirm this issue exists. I would be interested to know if the rendering of fonts under DirectWrite differs for everyone. What I do know is that apps created using the WPF also exhibit the same characteristics as Minefield does when DirectWrite is enabled. As far as I can see, the only feasible way around this is to stick to using the current Cleartype/GDI method for rendering text.
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
https://bugzilla.mozilla.org/show_bug.cgi?id=584724 this bug may be related.
Comment 3•14 years ago
|
||
This is a bug in gmail because they specify bold twice for that button. GDI was unable to enumerate all weights in the Arial family and would never be able to find the higher weights in the Arial Black font face. DirectWrite is. This is correct behavior.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Comment 7•14 years ago
|
||
This bug is even on the National Weather Service site( http://www.weather.gov/ ) and on a few other sites, but the National Weather Service site is the easiest to see. It looks OK in Firefox 3.6, other web browser, and Firefox 4 beta 8 and nightly without hardware acceleration on Windows 7, but does not look right in Firefox 4 beta 8 and the nightly build with hardware acceleration. I even looked at the code on the site and see <strong> and <b> tags. I have attached an image to show it so people can look at it easier.
Updated•14 years ago
|
Whiteboard: READ COMMENT 3 BEFORE COMMENTING
Bas, you say this is correct behavior, but whenever the b and strong tags are mentioned in the specifications, their effect is described as "bold," not "bolder." See http://www.w3.org/TR/html401/present/graphics.html#h-15.2.1 and also http://www.w3.org/TR/REC-html32-19970114#font-style Why did the Firefox (and Webkit, though I know you can't speak for them) developers decide to interpret these tags as "bolder"? One might surmise today that the intention was to set off the marked text even when it appears amidst already-bolded text, but considering that the specs make no mention of such behavior, and that this decision was made long before the font engine was capable of making such a distinction, that doesn't really make sense. So this is not necessarily "correct" behavior, though it appears to be *intended*. Seems to me, either the Firefox handling of these tags needs to change (b = "bold", which makes etymological sense, and which everyone has assumed until now), or the HTML5 spec should be modified to clearly and explicitly stipulate this new behavior.
Comment 9•13 years ago
|
||
Instead of moving this to resolved:invalid, it should probably be in website evangelism.
Assignee: nobody → english-us
Component: Graphics → English US
Product: Core → Tech Evangelism
QA Contact: thebes → english-us
Version: Trunk → unspecified
Updated•13 years ago
|
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 10•13 years ago
|
||
Complaints seen on Input: http://input.mozilla.com/en-US/search/?product=firefox&sentiment=sad&date_end=&date_start=&version=4.0b9&q=archive+gmail
Whiteboard: READ COMMENT 3 BEFORE COMMENTING → READ COMMENT 3 BEFORE COMMENTING, [Input]
Comment 11•13 years ago
|
||
it should be noted, however, that IE9 RC (also D2D) handles this in a way that does not look broken.
Comment 12•13 years ago
|
||
(In reply to comment #8) > Bas, you say this is correct behavior, but whenever the b and strong tags are > mentioned in the specifications, their effect is described as "bold," not > "bolder." > > See http://www.w3.org/TR/html401/present/graphics.html#h-15.2.1 > and also http://www.w3.org/TR/REC-html32-19970114#font-style > > Why did the Firefox (and Webkit, though I know you can't speak for them) > developers decide to interpret these tags as "bolder"? One might surmise today > that the intention was to set off the marked text even when it appears amidst > already-bolded text, but considering that the specs make no mention of such > behavior, and that this decision was made long before the font engine was > capable of making such a distinction, that doesn't really make sense. > > So this is not necessarily "correct" behavior, though it appears to be > *intended*. Seems to me, either the Firefox handling of these tags needs to > change (b = "bold", which makes etymological sense, and which everyone has > assumed until now), or the HTML5 spec should be modified to clearly and > explicitly stipulate this new behavior. The reason the default stylesheet uses 'bolder' rather than 'bold' is so that the correct behavior happens within nested tags. Consider this: <h1><strong>Strong</strong> should be bolder than other text</h1> If <strong> or <bold> has 'font-weight: bold' assigned to it, the word strong will appear with an identical font weight as other heading text. It was always been possible to find fonts on OSX with multiple bold weights but because of the way GDI artificially limited font families to one and only one bold weight, this sort of bug has passed under a lot of author's radar.
Comment 13•13 years ago
|
||
(In reply to comment #11) > Created attachment 512072 [details] > (animated png - view in FF) multi-browser gmail rendering showing cleartype > on/off 2 sec frame delay > > it should be noted, however, that IE9 RC (also D2D) handles this in a way that > does not look broken. This is somewhat of an apples-and-oranges comparison, your screenshot looks like it's on a machine with Cleartype disabled by default. IE9 (along with IE7/8) forces on Cleartype rendering of platform fonts which we do not. So Firefox 4 draws Arial Black without Cleartype, IE9 draws Arial Black with Cleartype. I would definitely agree that it looks like crap but so will a lot of fonts without Cleartype enabled.
Comment 14•13 years ago
|
||
(In reply to comment #13) > This is somewhat of an apples-and-oranges comparison, your screenshot looks > like it's on a machine with Cleartype disabled by default. IE9 (along with > IE7/8) forces on Cleartype rendering of platform fonts which we do not. So > Firefox 4 draws Arial Black without Cleartype, IE9 draws Arial Black with > Cleartype. I would definitely agree that it looks like **** but so will a lot > of fonts without Cleartype enabled. the attachment is an animated PNG with 2 frames, the first is cleartype off and second is on. yes, i disable cleartype on my systems because it often looks LESS clear. there are also many instances when D2D fonts look like trash (with speculation of a fix coming from MS in a service pack before IE9 final). i'm not sure sure it's apples-to-oranges unless the extra button spacing is added as a result of the HTML5 parser in FF4, in which case i should add an iteration of FF4 with D2D disabled...
Comment 15•13 years ago
|
||
FF4 with "gfx.direct2d.disabled = true" looks the same as FF3.6 so this issue really has nothing to do with cleartype and i never suggested that it did. i just made cleartype on/off variations for my own evil plot.
Comment 16•13 years ago
|
||
Leon, the FF4 with D2D version doesn't seem to be part of the animation, it always shows with Cleartype off. Not sure what relates to the HTML5 parser but, yes, there are multiple text rendering paths possible in FF4: DirectWrite rendering, harfbuzz shaping, Cleartype (default) DirectWrite rendering, DirectWrite shaping, Cleartype DirectWrite rendering, harfbuzz shaping, Cleartype off (*) DirectWrite rendering, DirectWrite shaping, Cleartype off GDI rendering, harfbuzz shaping, Cleartype GDI rendering, Uniscribe shaping, Cleartype GDI rendering, GDI shaping, Cleartype GDI rendering, harfbuzz shaping, no Cleartype GDI rendering, Uniscribe shaping, no Cleartype GDI rendering, GDI shaping, no Cleartype (*) = your default settings The Uniscribe vs. GDI shaping decision is made based on the version of the OS (i.e. WinXP vs. Win7) and the text being rendered. The harfbuzz vs. platform shaper is determined by the 'gfx.font_rendering.harfbuzz.level' setting, a value of '0' effectively disables harfbuzz. DirectWrite vs. GDI is currently controlled by the hardware you are using and the various D2D/DirectWrite prefs (see gfx.* prefs), if your hardware is supported you get DirectWrite, GDI otherwise.
Comment 17•13 years ago
|
||
okay, after some more testing. you're right, IE9 appears to use cleartype regardless. also FF4 reads cleartype settings only upon launch and not dynamically (which i did not account for). so that's out of the way. so with cleartype enabled and default settings - FF4 definitely looks better, smooth and non-garbagey, but still suffers from the button padding issue, while IE9 RC does not. that's more of an oranges-to-oranges.
Attachment #512072 -
Attachment is obsolete: true
Comment 18•13 years ago
|
||
i should mention, too, that the actual font looks pixel-for-pixel identical in both browsers. the 3rd variation (bottom) is with the <b> tag stripped out.
Comment 19•13 years ago
|
||
(In reply to comment #12) > The reason the default stylesheet uses 'bolder' rather than 'bold' is so that > the correct behavior happens within nested tags. Consider this: > > <h1><strong>Strong</strong> should be bolder than other text</h1> > > If <strong> or <bold> has 'font-weight: bold' assigned to it, the word strong > will appear with an identical font weight as other heading text. Yes, that was considered and addressed in my comment. My point was that this is not in fact "correct" behavior, with respect to the specs. They make no mention of setting off text visually within already-bolded text; as I pointed out and you confirmed, that was not even possible for the vast majority of computers until now. This confirms the specs' linguistic indications that <b> and <strong> have always been intended to achieve the effect of 'bold', not 'bolder'. As with any other style markup, user agents should simply ignore them within a redundant context. A developer can easily style either tag as 'bolder' if he finds it desirable, but I'd argue that shouldn't be the default style. It makes the well-established behavior of that markup suddenly inconsistent across browsers and platforms.
Comment 20•13 years ago
|
||
I agree with Jason M that inconsistency across browsers could be a problem here. Firefox 4 beta (12) is the only browser in which this "problem" appears, Firefox 3.6.13, Google Chrome 9 and MSIE 8 all display the Archive button at the same size as the other buttons. As for the discussion about whether this follows the specs or not, this reinterpretation effectively comes down to changing the rules during the game... (UA used: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12)
Comment 21•13 years ago
|
||
(In reply to comment #12) > The reason the default stylesheet uses 'bolder' rather than 'bold' is so that > the correct behavior happens within nested tags. Consider this: > > <h1><strong>Strong</strong> should be bolder than other text</h1> On the other hand, browsers generally render font-weights of 700, 800, and 900 the same. I assume (you'd know much better, correct me if I'm wrong) that lots of common fonts don't even provide more than one bold weight, so browsers won't be able to display those fonts that bold no matter what. So authors will write pages that accidentally nest <b> inside something that already makes it bold, it will look the same to them, and some users will see it extra-bold -- which the author doesn't want. Like in the places reported here. So if you really have something like <h1><strong>Foo</strong> bar</h1>, is that because the author wanted it to stand out? Or because the author didn't notice the nesting, like because the outer bolding is due to some stylesheet rule or because the markup was pasted together by a script? The latter seems at least as likely in practice, and it has the advantage of consistency. Authors who want the inconsistent behavior can always specify font-weight: bolder explicitly, but it's not reliable enough that it should be used anywhere by default, IMO. I've filed a bug against HTML5 on the fact that it doesn't match browsers: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=12154>. Currently I think it should be closed WONTFIX and the browsers should change. If you think otherwise, I suggest you comment there.
Comment 22•13 years ago
|
||
webkit changed <strong> and <b> to mean bold rather than bolder. https://bugs.webkit.org/show_bug.cgi?id=56400
Comment 23•13 years ago
|
||
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
Comment 24•12 years ago
|
||
Just a comment to note that the Archive button in Gmail now renders in Arial Bold, not in Arial Black. So now we have to deal with the spec being changed to match Webkit, *sigh*, as per the last comment.
Comment 25•12 years ago
|
||
Spec now agrees that it should be 'bolder'.
Comment 26•10 years ago
|
||
Old bug Resolving as INVALID. Reopen with precise analysis and/or screenshots of the issue (if it still exists).
Assignee: english-us → nobody
Status: REOPENED → RESOLVED
Closed: 14 years ago → 10 years ago
Component: English US → Desktop
Resolution: --- → INVALID
Whiteboard: READ COMMENT 3 BEFORE COMMENTING, [Input] → [country-all]
Assignee | ||
Updated•5 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•