User-Agent: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; sk; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; sk; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre When you enable DirectWrite, the vertical size of Firefox Button will increase. Reproducible: Always

This looks like a font rendering change. UX team, should the size of the button change in response?

(In reply to comment #3) > UX team, should the size of the button change in response? No, the button should match the default size of the other window buttons(min/max/close). Right now the CSS is setting the size of the button with padding using em. Which might be why the button size would change if the font rendering changes.

Can someone confirm this?

Just a note: The bold font occurs only in my current profile, but not in clean profile. Not sure why, but the size of the button itself is changing regardless which profile I'm using.

I can't block on this until it's confirmed. Please renom once this bug is confirmed.

I've seen this too. Seems font related.

Happens to me also.

We will get different font metrics with DirectWrite. The Firefox button should be sized such that they don't negatively affect it!

We deal with the height, but what about the overly bold font? Looks pretty bad if you compare the two screenshots.

Peter suggested it doesn't always happen; have you seen it too, Dão?

Looks slightly bolder with DirectWrite over here, but not like in the attached screenshot.

(In reply to comment #12) > Peter suggested it doesn't always happen; have you seen it too, Dão? Apparently Gavin sees it: https://bug555845.bugzilla.mozilla.org/attachment.cgi?id=468744

That screenshot is from johnath's new machine, in case you want to see it in person, Joe!

I only want to block on the investigation of what's making this font apparently render bolder.

Here is picture of the bug on my PC. From user view it seems like easy fix, can someone work a little bit on this? OS: Windows 7 GPU: Nvidia 8400GS Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100903 Firefox/4.0b6pre

This bug will cause problems with https://bugzilla.mozilla.org/show_bug.cgi?id=593950 Basically, if the gap between min/max/close buttons and tabs is reduced to the designed 3px (?), there will be no room between tabs and the Firefox button when D2D is on (without D2D we get the correct gap, since the Firefox button is the same size with the window controls).

I've found similar entry: Bug 601152

John, could you have a quick look? This sounds like WONTFIX to me but I'm not 100% sure.

This is a quirk with DirectWrite in general. Text of websites shift whenever its enabled. It even causes a slight artifacting or mirroring issue in Google Reader when in list view.

(In reply to comment #20) > John, could you have a quick look? This sounds like WONTFIX to me but I'm not > 100% sure. ping?

The font metrics for the two cases is different: GDI metrics: 0[2ab098]: (FindFontForStyle) name: Segoe UI, sty: 00, wt: 700, sz: 12.0 -> Segoe UI Bold Font: 04F9D748 (Segoe UI Bold) size: 12.000000 emHeight: 12.000000 emAscent: 9.000000 emDescent: 3.000000 maxAscent: 12.000000 maxDescent: 3.000000 maxAdvance: 27.000000 internalLeading: 3.000000 externalLeading: 0.000000 spaceWidth: 3.000000 aveCharWidth: 7.000000 xHeight: 6.000000 uOff: -1.000000 uSize: 1.000000 stOff: 3.000000 stSize: 1.000000 supOff: 6.000000 subOff: 2.000000 0[2ab098]: InitTextRun 4e61508 fontgroup 34347a8 (Segoe UI) lang: en-us len 10 TEXTRUN " Minefield" ENDTEXTRUN DirectWrite metrics: 0[52b098]: (FindFontForStyle) name: Segoe UI, sty: 00, wt: 700, sz: 12.0 -> Segoe UIBold Font: 03DBF920 (Segoe UIBold) size: 12.000000 emHeight: 12.000000 emAscent: 9.176471 emDescent: 2.823529 maxAscent: 13.000000 maxDescent: 4.000000 maxAdvance: 21.855469 internalLeading: 4.000000 externalLeading: 0.000000 spaceWidth: 3.310547 aveCharWidth: 7.078125 zeroOrAve: 6.902344 xHeight: 6.000000 uOff: -1.042969 uSize: 1.000000 stOff: 3.105469 stSize: 1.000000 supOff: 6.000000 subOff: 6.000000 0[52b098]: InitTextRun 551a728 fontgroup 54d8ca0 (Segoe UI) lang: en-us len 10 TEXTRUN " Minefield" ENDTEXTRUN I need to dig into the layout code a bit more to figure out the exact calculation used but I would bet the height is set to (maxAscent + maxDescent + internalLeading). That would explain the slightly different heights, 18px vs. 20px. GDI code: if (0 < GetOutlineTextMetrics(dc.GetDC(), sizeof(oMetrics), &oMetrics)) { mMetrics->emHeight = metrics.tmHeight - metrics.tmInternalLeading; gfxFloat typEmHeight = (double)oMetrics.otmAscent - (double)oMetrics.otmDescent; mMetrics->emAscent = ROUND(mMetrics->emHeight * (double)oMetrics.otmAscent / typEmHeight); mMetrics->emDescent = mMetrics->emHeight - mMetrics->emAscent; mMetrics->maxAscent = metrics.tmAscent; mMetrics->maxDescent = metrics.tmDescent; DirectWrite code: mFontFace->GetMetrics(&fontMetrics); mMetrics.xHeight = ((gfxFloat)fontMetrics.xHeight / fontMetrics.designUnitsPerEm) * mAdjustedSize; mMetrics.maxAscent = ceil(((gfxFloat)fontMetrics.ascent / fontMetrics.designUnitsPerEm) * mAdjustedSize); mMetrics.maxDescent = ceil(((gfxFloat)fontMetrics.descent / fontMetrics.designUnitsPerEm) * mAdjustedSize); mMetrics.internalLeading = ceil(((gfxFloat)(fontMetrics.ascent + fontMetrics.descent - fontMetrics.designUnitsPerEm) / fontMetrics.designUnitsPerEm) * mAdjustedSize); The inclusion of ceil() was done for bug 549190.

In case the font metrics are correct, bug 610071 will take care of not screwing up the button size. The bold rendering is still an issue (see the screenshots on <http://blog.mozilla.com/rstrong/2010/11/06/what-to-do/>).

The excessively bold rendering seems to happen only with D2D enabled.

Changed name of bug. Dao, fill bug for bold font. Thanks for fixing them!

Enabling HW acceleration causes increase of size: 1. On FXB's bottom by 1px, 2. On top of tabs by 1px.

Forgot to ask: Should I fill another bug for it? Or it is something else?

Not happening anymore.