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)

x86
Windows 7
defect
Not set
normal

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).
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Attached image 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.
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.
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
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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]
it should be noted, however, that IE9 RC (also D2D) handles this in a way that does not look broken.
(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.
(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.
(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...
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.
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.
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
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.
Depends on: 635640
(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.
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)
(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.
webkit changed <strong> and <b> to mean bold rather than bolder. https://bugs.webkit.org/show_bug.cgi?id=56400
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.
Spec now agrees that it should be 'bolder'.
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 ago10 years ago
Component: English US → Desktop
Resolution: --- → INVALID
Whiteboard: READ COMMENT 3 BEFORE COMMENTING, [Input] → [country-all]
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: