429605 - font-size-adjust results in incorrectly-sized text on some platforms

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Chris Lawrence]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041704 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9pre) Gecko/2008041610 Minefield/3.0pre

Under Linux with trunk, font-size-adjust appears to shrink the first choice font even if its size is correctly specified; with Calibri, the effect is more dramatic than with Verdana, but it is noticeable with both typefaces.  Testing with trunk under OS X reveals that font handling there is essentially correct.

Reproducible: Always

Steps to Reproduce:
Load a web page with font-size-adjust specified in the style sheet.
Actual Results:  
Text is smaller than expected.

Expected Results:  
Text should be same size (modulo rounding error) as with no font-size-adjust specified.

Comment 1

[Chris Lawrence]

Attachment: Demonstration of bug.

Comment 2

[Chris Lawrence]

Initial discussion of this problem was in bug 130473.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: sample to test font-size-adjust sensitivity to hinting

The calculation of font size when using font-size-adjust should be based on unhinted metrics. Basing the adjustment on a hinted metric for the x-height of the original (unadjusted) font is not useful because once the adjustment is applied, the hinted outline may be significantly different.

The attached sample can be used to illustrate the surprising effect of this issue. It uses

   .a { font-family: sans-serif; font-size: 15pt; font-size-adjust: 0.8; }
   .b { font-family: sans-serif; font-size: 30pt; font-size-adjust: 0.4; }

to define two styles that would be expected to use the same font size. However, loading this test on Linux or Windows and zooming the view to various sizes, the two lines often differ considerably. Sometimes one is larger, sometimes the other (and occasionally they may happen to match).

On Mac OS X, the two styles do match at all zoom levels as the metrics are not affected by size-specific hinting.

Comment 5

[John Daggett (:jtd)]

Jonathan, why does this depend on bug 532533?  That's a Mac bug.  Is the implication that we need to read font tables directly to resolve this?

Comment 6

[Jonathan Kew [:jfkthame]]

Yes; as mentioned in bug 532533 comment #59, the patch there provides the code needed to read precise metrics and thus fix this.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Chris, 
Please attach a PNG or JPG or other image capture of what the first
attachment _should_ look like if properly rendered.

Comment 8

[Stanimir Stamenkov]

Attachment: Screenshot - correct rendering of attachment 316363

Made using SeaMonkey 1.1.18 on Windows XP.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Stanimir, Thank you.  That helps clarify it a LOT.

Comment 10

[RNicoletto]

Attachment: Google Chrome vs. Mozilla Firefox

Rendering of attachment 316363 [details] with Mozilla Firefox 3.6.9 and Google Chrome 6.0.472.55 on Windows XP Professional.

Comment 11

[Stanimir Stamenkov]

Does Chrome support font-size-adjust at all (test with attachment 368494 [details])?

Comment 12

[philippe (part-time)]

(In reply to comment #11)
> Does Chrome support font-size-adjust at all (test with attachment 368494 [details])?

No. WebKit doesn't support font-size-adjust.

Comment 13

[Stanimir Stamenkov]

I don't know how this is related but it appears the problem is not visible on Windows 7 (may be Vista too?) when Direct Write is enabled (which is the default with current nightlies).

Comment 14

[Stanimir Stamenkov]

Any chance this could be addressed for Firefox 7?

Comment 15

[Benoit Jacob [:bjacob] (mostly away)]

The bug still occurs in Firefox 11 (nightly). What should we do about it?

Comment 16

[Gérard Talbot]

(In reply to Chris Lawrence from comment #1)
> Created attachment 316363 [details]
> Demonstration of bug.

Right now, I see a *_tiny_* difference (hard to say what is the difference in terms of pixel; the difference could be the anti-aliasing ... ) with regards to the Verdana test.
In your expected results, you mention "(modulo rounding error)" but rounding up or down do affect rendering and layout in Firefox and in other browsers.

3 suggestions to improve your test.

1-
Would it be possible for you to change/replace 0.55 with 0.547 ?
For DejaVu Sans, I get 0.547 at both
http://www.brunildo.org/test/aspect-lh-table2.html
and
http://www.cs.tut.fi/~jkorpela/x-height.html

2-
Also, the test would be more revealing if font-size was set intentionally to a very large value, say, 75px or 100px. <h1> is 2em, which should be 32px.

3-
Also, if you want to compare respective height of 2 objects, then it is best to place them horizontally, side by side, with a background-image of a grid.

Under Linux Kubuntu 14.03 (raring), KDE 4.10.3, Calibri is not by default installed. So, that part of attachment 316363 [details] will not apply.

I am using Firefox 21.

Comment 17

[Gérard Talbot]

For Verdana, I get 0.547 at both
http://www.brunildo.org/test/aspect-lh-table2.html
and
http://www.cs.tut.fi/~jkorpela/x-height.html
under Windows XP SP3

Comment 18

[Gérard Talbot]

Good news!

I've made more tests and I now think that attachment 316363 [details] is not a correct test.

Please load
http://www.gtalbot.org/BugzillaSection/Bug429605.html

Precondition: you should have font face "DejaVu Sans" and font face "Padauk" installed. This should be the case for Linux users (debian distros, Ubuntu variant). I could create the same test for Windows users.

The blue glyphs represent a normal font declaration. The orange glyphs are a fallback font that uses a font-size-adjust declaration. Now, both blue and orange "x" should be equal height, perfectly equal height. It does not mean that other glyphs ("T" and "L") will have or use the same height. ("T" and "L" are ideal glyphs for this kind of test as part of them have horizontal line and so respective vertical position can be compared more easily, easier to notice.)

Figure 19 of/in 

http://dev.w3.org/csswg/css-fonts/#propdef-font-size-adjust

also demonstrate this: the lower part of the "b" glyphs, below the ascender line have identical height but the ascender part of the "b" glyphs do not have the same height. And so, the "b" glyphs have not the same height. Just like in my test: the "T" glyphs and the "L" glyphs do not have the same height. And that's okay.

KDE 4.10.3, i686, Firefox 21 (buildID = 20130512193902) here.

So, I think this bug report is INVALID.

Comment 19

[Jonathan Kew [:jfkthame]]

Not entirely. If you try my testcase (attachment 368494 [details]) on WinXP, or Win7/8 with hardware acceleration *DIS*abled (i.e., using the GDI font backend, not DirectWrite), you'll see that there is still a visible discrepancy between the two lines at various zoom factors.

I also see a significant discrepancy with that testcase on Linux, using DejaVu Sans. Again, try using page-zoom to view at various sizes.

Comment 20

[Gérard Talbot]

(In reply to Stanimir Stamenkov from comment #11)
> Does Chrome support font-size-adjust at all (test with attachment 368494 [details]
> [details])?

font-size-adjust is supported in Chrome but you must activate, must enable the enable-experimental-web-platform-features flag in Chrome.
In Chrome, type in the address bar, the url:
chrome://flags/#enable-experimental-web-platform-features
then enable it and restart (a button inside a panel at bottom of page will offer you to do so) Chrome.

attachment 368494 [details] passes in Chrome 50.0.2661.102

http://www.gtalbot.org/BugzillaSection/Bug429605.html 
also passes in Chrome 50.0.2661.102

but I must say that I use Linux only.