Last Comment Bug 429605 - font-size-adjust results in incorrectly-sized text on some platforms
: font-size-adjust results in incorrectly-sized text on some platforms
Status: NEW
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: Other All
: -- normal with 3 votes (vote)
: ---
Assigned To: Jonathan Kew (:jfkthame)
:
:
Mentors:
: 558893 (view as bug list)
Depends on: 532533
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-17 21:48 PDT by Chris Lawrence
Modified: 2016-05-21 17:00 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Demonstration of bug. (1.06 KB, text/html)
2008-04-17 21:49 PDT, Chris Lawrence
no flags Details
sample to test font-size-adjust sensitivity to hinting (514 bytes, text/html)
2009-03-20 01:54 PDT, Jonathan Kew (:jfkthame)
no flags Details
Screenshot - correct rendering of attachment 316363 (9.50 KB, image/png)
2010-06-13 08:29 PDT, Stanimir Stamenkov
no flags Details
Google Chrome vs. Mozilla Firefox (30.73 KB, image/png)
2010-09-09 06:27 PDT, RNicoletto
no flags Details

Description Chris Lawrence 2008-04-17 21:48:24 PDT
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 2008-04-17 21:49:21 PDT
Created attachment 316363 [details]
Demonstration of bug.
Comment 2 Chris Lawrence 2008-04-17 21:55:14 PDT
Initial discussion of this problem was in bug 130473.
Comment 3 Jonathan Kew (:jfkthame) 2009-03-20 01:54:58 PDT
Created attachment 368494 [details]
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 4 Jonathan Kew (:jfkthame) 2010-04-13 01:20:46 PDT
*** Bug 558893 has been marked as a duplicate of this bug. ***
Comment 5 John Daggett (:jtd) 2010-04-13 02:09:43 PDT
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) 2010-04-13 02:20:06 PDT
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) 2010-06-12 10:37:05 PDT
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 2010-06-13 08:29:49 PDT
Created attachment 450926 [details]
Screenshot - correct rendering of attachment 316363 [details]

Made using SeaMonkey 1.1.18 on Windows XP.
Comment 9 Nelson Bolyard (seldom reads bugmail) 2010-06-13 15:39:25 PDT
Stanimir, Thank you.  That helps clarify it a LOT.
Comment 10 RNicoletto 2010-09-09 06:27:09 PDT
Created attachment 473501 [details]
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 2010-09-13 01:10:35 PDT
Does Chrome support font-size-adjust at all (test with attachment 368494 [details])?
Comment 12 philippe (part-time) 2010-09-13 01:23:17 PDT
(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 2010-10-30 07:44:03 PDT
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 2011-05-24 12:01:30 PDT
Any chance this could be addressed for Firefox 7?
Comment 15 Benoit Jacob [:bjacob] (mostly away) 2011-12-02 14:09:21 PST
The bug still occurs in Firefox 11 (nightly). What should we do about it?
Comment 16 Gérard Talbot 2013-05-15 12:00:16 PDT
(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 2013-05-15 12:19:28 PDT
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 2013-05-15 13:44:09 PDT
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) 2013-05-15 14:08:13 PDT
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 2016-05-21 17:00:42 PDT
(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.

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