Last Comment Bug 589124 - [D2D] 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 b...
Status: RESOLVED INVALID
[country-all]
:
Product: Tech Evangelism
Classification: Other
Component: Desktop (show other bugs)
: unspecified
: x86 Windows 7
: -- normal with 4 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://mail.google.com/mail/?shva=1
: 584724 586447 613826 (view as bug list)
Depends on: 635640
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-20 04:16 PDT by Reece H. Dunn
Modified: 2014-06-17 17:33 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Screenshot of bug (23.63 KB, image/png)
2011-01-09 01:56 PST, advcomp2019
no flags Details
(animated png - view in FF) multi-browser gmail rendering showing cleartype on/off 2 sec frame delay (578.79 KB, image/png)
2011-02-13 17:15 PST, Leon Sorokin
no flags Details
IE9 vs FF4 defaults + d2d (W7x64) (182.57 KB, image/png)
2011-02-13 18:53 PST, Leon Sorokin
no flags Details

Description Reece H. Dunn 2010-08-20 04:16:13 PDT
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).
Comment 1 Olipro 2010-09-21 13:47:30 PDT
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.
Comment 2 rush_ad 2010-09-29 16:45:09 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=584724

this bug may be related.
Comment 3 Bas Schouten (:bas.schouten) 2010-09-29 20:24:00 PDT
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.
Comment 4 Bas Schouten (:bas.schouten) 2010-09-29 20:24:26 PDT
*** Bug 584724 has been marked as a duplicate of this bug. ***
Comment 5 Kevin Brosnan 2010-11-28 17:08:48 PST
*** Bug 613826 has been marked as a duplicate of this bug. ***
Comment 6 Kevin Brosnan 2011-01-09 00:42:15 PST
*** Bug 586447 has been marked as a duplicate of this bug. ***
Comment 7 advcomp2019 2011-01-09 01:56:21 PST
Created attachment 502329 [details]
Screenshot of bug

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.
Comment 8 Jason M 2011-01-10 07:33:18 PST
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 Aakash Desai [:aakashd] 2011-01-20 08:02:13 PST
Instead of moving this to resolved:invalid, it should probably be in website evangelism.
Comment 11 Leon Sorokin 2011-02-13 17:15:14 PST
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.
Comment 12 John Daggett (:jtd) 2011-02-13 17:34:24 PST
(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 John Daggett (:jtd) 2011-02-13 17:38:45 PST
(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 Leon Sorokin 2011-02-13 17:50:16 PST
(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 Leon Sorokin 2011-02-13 17:57:33 PST
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 John Daggett (:jtd) 2011-02-13 18:06:35 PST
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 Leon Sorokin 2011-02-13 18:53:57 PST
Created attachment 512089 [details]
IE9 vs FF4 defaults + d2d (W7x64)

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.
Comment 18 Leon Sorokin 2011-02-13 18:56:33 PST
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 Jason M 2011-02-23 13:44:27 PST
(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 bugzilla_moz.20.ibyte 2011-02-27 05:44:11 PST
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 :Aryeh Gregor (working until September 2) 2011-03-15 11:53:49 PDT
(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 Dão Gottwald [:dao] 2012-01-03 14:03:54 PST
webkit changed <strong> and <b> to mean bold rather than bolder. https://bugs.webkit.org/show_bug.cgi?id=56400
Comment 24 John Daggett (:jtd) 2012-02-01 17:09:32 PST
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 Hixie (not reading bugmail) 2012-12-09 21:52:12 PST
Spec now agrees that it should be 'bolder'.
Comment 26 Karl Dubost :karlcow 2014-06-17 17:33:43 PDT
Old bug Resolving as INVALID. Reopen with precise analysis and/or screenshots of the issue (if it still exists).

Note You need to log in before you can comment on or make changes to this bug.