Open
Bug 480196
Opened 15 years ago
Updated 2 years ago
[Mac] OS X type rendering - text baseline is shifted upwards, effectively no-longer centered vertically within the line-height
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: ydnar, Unassigned)
References
()
Details
Attachments
(2 files)
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
Comment 1•15 years ago
|
||
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.
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
Comment 4•15 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•15 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•15 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•15 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•15 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•15 years ago
|
||
Comment 10•15 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•15 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.
Comment 12•15 years ago
|
||
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
Comment 13•15 years ago
|
||
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
Comment 15•15 years ago
|
||
(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•15 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•7 years 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?
Comment 18•6 years ago
|
||
Comment 19•6 years ago
|
||
I created a test case that illustrates the problem. It has to do with the differing ways in which browsers align baselines and how they align a line of text when the line-height is smaller than the bounding box of the font. Here's the test case: https://codepen.io/aparajita/pen/opmWdV I attached an image that shows the difference between the bounding box of the font (in the middle) and how that same font and its line are aligned with a line-height of 1, which is smaller than the bounding box. In every case I have looked at where the line-height is smaller than the bounding box, other browsers seem to keep the baseline stationary within the bounding box and then shrink the top/bottom of the bounding box more or less equally until it equals line-height. I can't figure out what Firefox is doing. Hope this helps.
Comment 20•6 years ago
|
||
Hmm... it's more complicated than I thought. Turns out all of the other browsers may actually be at fault on macOS, because *all* browsers on Windows display my test case exactly as Firefox does on macOS.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•