[Mac] OS X type rendering - text baseline is shifted upwards, effectively no-longer centered vertically within the line-height

UNCONFIRMED
Unassigned

Status

()

Core
Layout: Text
UNCONFIRMED
9 years ago
5 months ago

People

(Reporter: ydnar, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6

It seems that Firefox’s type rendering in OS X shifts the baseline of all text up by ~1px, or some value that seems semi-deterministic based on the font-size and line-height.

WebKit and IE produce the expected results, with the text being rendered vertically centered within the line-height block.

This page demonstrates the difference: http://nb.io/test/baseline

Reproducible: Always

Steps to Reproduce:
1. Create type, say font-size: 30px; line-height: 36px;
Actual Results:  
The type is not vertically centered within a block that’s 36px tall.

http://s.nb.io/_s/0/i/type-mozilla.png

Expected Results:  
The type should be vertically centered within the line-height block.

http://s.nb.io/_s/0/i/type-webkit.png
Not sure I understand this report. Yes, the positioning is different -- but it
looks to me as if the Mozilla text is closer to being "vertically centered
within the line-height block", in many cases. Compare the gaps above and below
the tips of the parentheses in the images provided; the Webkit text often has
significantly more space above than below, within the line-height extent.

I'm not saying which is preferable -- maybe the slightly lower Webkit text
looks better? But I don't see how the images fit the description of the issue.
How does one evaluate the "vertically centered-ness" of text, other than
looking at the amount of gap above and below glyphs like the parens (which
typically extend to the ascent and descent lines of the font, or to the edges
of the em-square). Yes, I can imagine other ways to try and assess this, but
it's not clear to me that one is more "right" than the others.
(Reporter)

Comment 2

9 years ago
I realize the initial description of the problem may have been inadequate. A better way to describe it might be this:

“Within a given line-height, the text should be perceptually centered based on the block defined by the baseline and ascender-height.”

I’ve updated the example with links that resemble buttons. This demonstrates the difference more clearly, particularly with all-capital and non-latin glyphs (in this case Chinese):

    http://nb.io/test/baseline

Updated

8 years ago
Duplicate of this bug: 502309

Comment 4

8 years ago
What matters here is that the positioning is consistent across all browsers.
Firefox 3.x for Windows renders the baseline in it's proper location.

The OSX build of Firefox (3.x), however, does not render it the same as any other browser. 

Opera 9.6, Chrome 2.0, IE7 in Windows, Safari 3/4 in OSX and Windows, and Firefox 3.5 for Windows all render the baseline consistently.

I will upload another example shortly.

Comment 5

8 years ago
here is another example with references to what the other browsers render:
http://www.arjunmehta.net/temp/bugzilla/baselineShift.html

It actually seems to be more of an issue with the spacing above the text in rather than the baseline.

In all other browsers, the spacing from the top of the L and the bottom of the L is the same (or pretty close) as it should be.

But in FF OSX the top spacing is made equal to the bottom spacing of the descender (see the 'p' in ipsum) instead of the spacing of the baseline.

This is exaggerated by increasing the text size of the page.

Comment 6

8 years ago
(In reply to comment #5)
> here is another example with references to what the other browsers render:
> http://www.arjunmehta.net/temp/bugzilla/baselineShift.html

There is a problem with your testcase :-) It specifies Helvetica for font-family. Nothing wrong perse, but

1. it has different metrics than Arial (that makes it harder to compare between Windows and OS X).

2. it is known that WebKit has some hacks to force Helvetica to take the metrics of Arial (Dave Hyatt mentioned/admitted[1] this on the www-style mailing list sometime ago) - that also applies to e.g Times, set to match Times New Roman.

[1] http://lists.w3.org/Archives/Public/www-style/2008Jan/0330.html

If you remove 'helvetica' out of your stylesheet, the results between Safari and Gecko are much much closer.

Comment 7

8 years ago
Hi there,

Even if you use the default typeface, it is still adding the wrong (non-standard) spacing above the text.

It seems as though (judging by how all the other browsers are rendering the type, including the Windows version of FF) the spacing above the ascender should be the same as the spacing below the baseline, NOT the spacing below the descender.

ie. The spacing above the L, should be the same as the spacing below the L. Not the same as the spacing below the p.

Comment 8

8 years ago
(In reply to comment #7)
> Hi there,
> 
> Even if you use the default typeface, it is still adding the wrong
> (non-standard) spacing above the text.

What do you mean by 'the default typeface' ? The one(s) set in preferences ? By default that is 'Helvetica' for sans-serif and 'Times' for serif (for OS X; for Windows it is Arial and Times New Roman).
 
> It seems as though (judging by how all the other browsers are rendering the
> type, including the Windows version of FF) the spacing above the ascender
> should be the same as the spacing below the baseline, NOT the spacing below the
> descender.

Assuming yes to the question above, the display of your original test case won't change... Have you tried setting the style for your testcase to Arial ?

One other thing that can affect the testcase: the line-height. In your testcase, it is set, by default, to the 'normal' keyword. On OS X, 'normal' computes to 1.000 for Helvetica, and 1.150 for Arial.

Comment 9

8 years ago
Created attachment 386859 [details]
arjun test case reworked

Comment 10

8 years ago
philippe; My bad. I share a profile between OSX and Windows so they both have the "default font" set to Times. I thought this was the Firefox standard but I guess not.

I did a little test run with a bunch of different fonts and you're right, there is an inconsistency. Some typefaces are rendered as expected and some are not (Times and Helvetica).

http://www.arjunmehta.net/temp/bugzilla/baselineShiftFonts.html

I'm not sure what other fonts are affected, but is it safe to say that there is a problem here?

As I mentioned, the issue here is that the fonts should be rendered consistently across both builds. A web designer expects that if it looks a certain way in Firefox for Windows (or any other browser), that it will be rendered pretty much the same in Firefox for OSX.

If webkit is making the adjustment, that is likely an indication that this is an important issue to consider.

The only other browser that I tested which doesn't render it with the same consistency is Opera 9.64 for OSX.

Comment 11

8 years ago
I am having the same issue.  Here is my test case: http://test.kingdesk.com/position/

The problem is font dependent.  I have confirmed Times and Helvetica have issues.  The problem is exaggerated at larger font sizes.

I share the same fonts between a Windows and Mac install.  Every browser displays them the same, except Firefox for Mac.  I have tested in Safari for Windows & Mac, Chrome for Windows (and the Mac developers build), Opera for Windows and Mac, IE6 7 and 8 on Windows, and Firefox in Windows & Mac.

Only Firefox for Mac has this alignment problem.

Don't know why this is still unconfirmed... This bug is not difficult to confirm.
I will go ahead and confirm this bug since I do see the issue on the testcase in Comment 11 using  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b3pre) Gecko/20091113 Namoroka/3.6b3pre. When I compare to Safari you can see the difference and I do agree it is easier to see when the font is larger.

I don't really see it in the URL bar example. Bug 528180 seems to be a dupe, but has an example in that bug where you can also see it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: OS X type rendering - text baseline is shifted upwards, effectively no-longer centered vertically within the line-height → [Mac] OS X type rendering - text baseline is shifted upwards, effectively no-longer centered vertically within the line-height
I forgot these bugs are supposed to be in the UNCO state until there is testcase, so moving it back to that state for now. So that will answer the question posed in Comment 11.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Duplicate of this bug: 528180
(In reply to comment #13)

The test case in comment 11 suffers from the same issue as discussed in comment 6 - 10. It uses 'Times'. As pointed out in comment 6, WebKit has a hack there, it (forces) matches the metrics for 'Times New Roman'. The there is a difference.
Opera 10 renders the test case in comment 11 the same as Gecko (1.9.++).

Comment 16

8 years ago
(In reply to comment #15)
> (In reply to comment #13)
> 
> The test case in comment 11 suffers from the same issue as discussed in comment
> 6 - 10. It uses 'Times'. As pointed out in comment 6, WebKit has a hack there,
> it (forces) matches the metrics for 'Times New Roman'. The there is a
> difference.
> Opera 10 renders the test case in comment 11 the same as Gecko (1.9.++).

Philippe,

You make an invalid assumption.  The test case in 11 exposes the rendering error with identical fonts installed. We are not comparing Times to Times New Roman or Helvetica to Arial. This is why I specified in 11 identical font installations in my Windows and Mac testing environments: Times to Times and Helvetica to Helvetica. The same exact .ttf files copied to each system.  The CSS rendering is not failing to backup fonts since the specified fonts are installed in both environments.

Comment 17

5 months ago
It's been eight years, bug still reproducible using http://test.kingdesk.com/position/

Is there a temporary workaround? And what needs to be done for this to be confirmed as a bug?
You need to log in before you can comment on or make changes to this bug.