Open Bug 429605 Opened 16 years ago Updated 1 year ago

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


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





(Reporter: lawrencc, Assigned: jfkthame)




(4 files)

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.
Attached file Demonstration of bug.
Component: General → GFX
Product: Firefox → Core
Version: unspecified → Trunk
Initial discussion of this problem was in bug 130473.
QA Contact: general → general
Product: Core → Core Graveyard
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.
Assignee: nobody → jfkthame
Ever confirmed: true
Component: GFX → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: general → thebes
Depends on: 532533
OS: Linux → All
Summary: font-size-adjust results in incorrectly-sized text under Linux → font-size-adjust results in incorrectly-sized text on some platforms
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?
Yes; as mentioned in bug 532533 comment #59, the patch there provides the code needed to read precise metrics and thus fix this.
Please attach a PNG or JPG or other image capture of what the first
attachment _should_ look like if properly rendered.
Made using SeaMonkey 1.1.18 on Windows XP.
Stanimir, Thank you.  That helps clarify it a LOT.
Rendering of attachment 316363 [details] with Mozilla Firefox 3.6.9 and Google Chrome 6.0.472.55 on Windows XP Professional.
Does Chrome support font-size-adjust at all (test with attachment 368494 [details])?
(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.
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).
Any chance this could be addressed for Firefox 7?
The bug still occurs in Firefox 11 (nightly). What should we do about it?
(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.

Would it be possible for you to change/replace 0.55 with 0.547 ?
For DejaVu Sans, I get 0.547 at both

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.

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.
Good news!

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

Please load

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

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.
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.
(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:
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 
also passes in Chrome 50.0.2661.102

but I must say that I use Linux only.
Severity: normal → S3
Component: Graphics → Layout: Text and Fonts
You need to log in before you can comment on or make changes to this bug.