Closed
Bug 931029
Opened 11 years ago
Closed 11 years ago
Inconsistent Arial font rendering of digits between Mac/Windows/Linux
Categories
(Core :: Graphics: Text, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: ziggy90127, Unassigned)
References
Details
(Keywords: regression, testcase)
Attachments
(6 files)
FireFox v24 Arial digit render problem.jpg
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1
Steps to reproduce:
Open web page with the following HTML:
<!DOCTYPE html>
<html>
<body>
<p style="font-family:arial">
0000000000.<br>
1111111111.<br>
2222222222.<br>
3333333333.<br>
4444444444.<br>
5555555555.<br>
6666666666.<br>
7777777777.<br>
8888888888.<br>
9999999999.<br>
</p>
</body>
</html>
Actual results:
Firefox v24 on Ubuntu 12.10 shows each row of digits as the same length, as it should.
Firefox v24 on Mac 10.8.5 shows the row of "1" digits as shorter than the others, which is incorrect.
Firefox v24 on Windows XP SP3 shows the row of "1" digits as shorter than the others, which is incorrect.
Expected results:
If you open the truetype Arial.ttf file with a font editor, you'll note that each digit 0-9 is the same width. FireFox on Windows and Mac is rendering the "1" digit with an incorrect, shorter, width. FireFox on Linux is rendering correctly. Safari 6.0.5/10.8.5, Chrome 30.0.1599.69/10.8.5, IE 6/Win XPSP3 also all render correctly.
|
||
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics: Text
Ever confirmed: true
Product: Firefox → Core
|
|
||
Comment 1•11 years ago
|
||
I can reproduce since Firefox 4, but not reproduce in Firefox3.6.
|
|
||
Comment 2•11 years ago
|
||
|
|
||
Comment 3•11 years ago
|
||
Regression window(m-c)(Windows7)
Good:
http://hg.mozilla.org/mozilla-central/rev/052a1c415457
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100314 Minefield/3.7a3pre ID:20100314214215
Bad:
http://hg.mozilla.org/mozilla-central/rev/8ff6056308bd
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100315 Minefield/3.7a3pre ID:20100315042737
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=052a1c415457&tochange=8ff6056308bd
Regressed by (Windows7):
8ff6056308bd Jonathan Kew — bug 502906 - part 3 - factor out Uniscribe and GDI shapers from Windows GDI font code. r=jdaggett
|
||
Comment 4•11 years ago
|
||
I think the actual "bug" here is that the Webkit rendering is different, not that the Linux rendering is different. The Linux rendering is a different font (look closely at the actual glyph form of "1" or "5" for example).
|
|
||
Comment 5•11 years ago
|
||
(In reply to John Daggett (:jtd) from comment #4)
Safari 7 / 10.9 renders the '1' line shorter than the others, similar to the screenshot (and Fx OS X) - I think Safari 6.1 /10.8.5 would render the same, but can't test it right now.
I increased the font size to 20 pt. In addition to FireFox v24 on Ubuntu, Mac, and Windows, I included shots of Safari and Chrome.
I agree, FireFox Linux is not using the Arial font. So there are 2 problems:
1) The glyph width for "1" is wrong on Mac and Windows.
2) FireFox Linux is using the wrong font.
|
|
||
Comment 8•11 years ago
|
||
This isn't a bug, it's simply the default kerning for digits with Arial. This is enabled by default in Firefox on all platforms but not in Chrome/Safari.
So you can explicitly disable kerning to get the desired behavior.
Let me know if you have an underlying problem that you're running into or please mark this invalid if this answers your concern.
|
|
||
Comment 9•11 years ago
|
||
As for Firefox on Linux not using Arial, I guess the question is whether you have Arial installed *and* whether fontconfig is automagically substituting another font. Since the font is relatively close in design, I'm guessing the latter.
|
|
||
Comment 10•11 years ago
|
||
(In reply to John Daggett (:jtd) from comment #8)
> Created attachment 822713 [details]
> testcase, arial digit kerning
>
> This isn't a bug, it's simply the default kerning for digits with Arial.
> This is enabled by default in Firefox on all platforms but not in
> Chrome/Safari.
>
> So you can explicitly disable kerning to get the desired behavior.
>
> Let me know if you have an underlying problem that you're running into or
> please mark this invalid if this answers your concern.
See screenshot on windows8.1.
Umm, The default kerning is different between IE11 and Firefox.
This is a compatibility problem between browser.....
|
|
||
Comment 11•11 years ago
|
||
Comodo Dragon's default is as same IE11.
So, only Firefox is different...
|
||
Comment 12•11 years ago
|
||
(In reply to Bob Smith from comment #0)
> If you open the truetype Arial.ttf file with a font editor, you'll note that
> each digit 0-9 is the same width.
If you open Arial.ttf with a font editor, you should also note that it defines a kern value for the glyph pair <one, one> (with a kerning value of -152/2048 of the em size, at least in the Windows 7 version of Arial that I checked). Therefore, it is expected that the spacing between a pair of successive "1" digits will be reduced by this amount, which is about 13% of the normal width of the <one> glyph (1139/2048). That's what the font designer calls for, and that's what Firefox does.
> FireFox on Windows and Mac is rendering
> the "1" digit with an incorrect, shorter, width.
No; as you can tell if you add a line such as "1010101010." to the testcase, the "1" digit is rendered with the same width as the other digits, as defined in the font.
However, when a pair of "1" digits occur together, the kern pair that is also defined in the font becomes applicable, and the spacing is adjusted accordingly.
According to http://dev.w3.org/csswg/css-fonts/#font-kerning-prop, the initial value for the 'font-kerning' property is 'auto', and 'auto' means "kerning is applied at the discretion of the user agent".
Furthermore, "the [OPENTYPE] specification suggests that kerning be enabled by default", which is exactly what Firefox does: it uses the "discretion" allowed by the CSS Fonts spec to do the right thing. So the Arial rendering here is not a bug, it is expected and correct behavior.
|
|
||
Comment 13•11 years ago
|
||
Install ttf-mscorefonts-installer on ubuntu12.04,
Then the behavior is same as Windows7.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
|
Reporter | |
Comment 14•11 years ago
|
||
Thanks for your work on this guys.
My take aways on this:
1) I didn't install Arial on Ubuntu before my test
2) I didn't use the "kerning" and "tracking" terms correctly.
2) Kerning defaults are different between FireFox and other browsers.
The reason I pursued this was, in the past, I wrote a Win32 program that relied on Arial digits being the same width, regardless of digit combinations. I'm trying to replicate this functionality on the web. I guess I'll have to wait for the "font-kerning" property to be implemented in FireFox.
|
|
||
Comment 15•11 years ago
|
||
(In reply to Bob Smith from comment #14)
> Thanks for your work on this guys.
>
> My take aways on this:
>
> 1) I didn't install Arial on Ubuntu before my test
> 2) I didn't use the "kerning" and "tracking" terms correctly.
> 2) Kerning defaults are different between FireFox and other browsers.
>
> The reason I pursued this was, in the past, I wrote a Win32 program that
> relied on Arial digits being the same width, regardless of digit
> combinations. I'm trying to replicate this functionality on the web. I
> guess I'll have to wait for the "font-kerning" property to be implemented in
> FireFox.
In the meantime, you could use the lower-level property
-moz-font-feature-settings: "kern" 0;
to explicitly turn off kerning.
Or use a font that is explicitly monospaced and does not have kerning.
(In general, if your page or site requires monospaced digits it would be better to use "font-family: monospace;" than a family name like Arial, which (a) may or may not be available, depending on the platform and the user's installed fonts, and (b) is not monospaced by design.)
You need to log in
before you can comment on or make changes to this bug.
Description
•