Helvetial
Published 11 years, 8 months pastMaybe all the cool kids already know this, but I didn’t, so I’ll document it for the rest of us: in Windows, Helvetica is not Helvetica: it’s Arial. It’s Arial even if you explicitly ask for Helvetica and fall back to a non-sans-serif font family and allow for no other choices — but it’s not Helvetica if you try to get to it indirectly.
To see what I mean, you can load up my testcase in any Windows browser — IE, Firefox, Chrome, whatever — assuming that you haven’t installed Helvetica on your Windows machine. (If you have, then I’d love to know what results you get.) Given that you haven’t installed Helvetica, you should see that three of the four bottom-bordered spans are using Arial. This can be determined due to the shapes of the “GR” characters — they are notably different between Helvetica and Arial. Here’s what I apply to the first test list item:
#l01 .s01 {font-family: Helvetica, monospace;}
#l01 .s02 {font-family: Arial, monospace;}
My result is that they use exactly the same face, and that face is Arial, which should not have happened. If Helvetica is not present, the first span should be rendered using a monospace font face. If it is present, then the first span should have different letterforms than the second.
But it’s the second line where things get really interesting. There, I assigned local copies of Helvetica and Arial (if they exist) to the invented family names “H” and “A”. Then I apply this to the second test list item:
#l02 .s01 {font-family: H, monospace;}
#l02 .s02 {font-family: A, monospace;}
The result should be the same as the first line, but it isn’t: the first span gets a fallback font face, and the second span gets Arial. So while the system redirects requests for Helvetica to Arial, it doesn’t do so in such a way that the invented family name “H” resolves to Arial, even though it was assigned Helvetica (or perhaps I should say “Helvetica”) as its source.
I’d be interested to know if there’s something I’ve overlooked or misunderstood here, because these waters are deep and I suspect my understanding of them is somewhat shallow.
Comments (14)
For me the results are:
Chrome: It all looks the same.
Firefox 19: #102 .s01 looks different, the other 3 look the same
I get all Arial for all the spans. I have Helvetica Neue installed. The only way I can get it to display is using @font-face rules with urls that link directly to the Helvetica Neue file. Generally when I’ve used Helvetica Neue for projects I include a copy of the font in a font folder or the root.
I’m using a Win7/64 bit machine. It doesn’t really matter what browser. Except for IE. I don’t have a .eot version of Helvetica, so it’ll always be whatever IE decides to choose for a font.
I updated the test (and the post) to lock things down as much as possible—adding a serif font to the
body, and replacingfantasywithmonospace. Force-reloads may be necessary.Looks like it’s caused by font aliases in Webkit when font cannot be found. I haven’t dug deep enough to work out why it wouldn’t fall back to the the family type instead.
Matt, I could easily be wrong, but I don’t see how this can be pinned on WebKit if the same behavior is seen in Firefox and IE.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
“Helvetica”=”Arial”
http://blogs.msdn.com/b/michkap/archive/2005/03/20/399322.aspx
I think it’s an obscure feature of the GDI stack that’s been around for a long time.
I’d not pin the problem exclusively on WebKit, but it explains part of the reason why I experienced the problem in Chrome on Ubuntu.
Looks like both browser and OS vendors make some assumptions on our behalf about what we mean by “Helvetica”. For example Windows has a registry entry (
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes) that specifies some default font substitutions to use, which includes a Helvetica to Arial mapping.For what it’s worth, for me – in Chromium on Linux, the two lines look exactly the same.
Nicholas and Matt, very interesting. I wonder why the substitution fails with custom family names.
The two lines look the same on OS X as well, Jeremy, in all the current browsers I have ready to hand. (Including Opera Next, which I guess isn’t current any more…)
For the second test, is the font(-file) named exactly ‘Helvetica’ in Windows? Not e.g. ‘Helvetica regular’ or something like that? The rules for
src: local()are pretty strict about this as I understand them.I don’t have Helvetica installed in my Windows VM’s, and can’t verify.
People having different fallback fonts for the ‘H’ is possibly due to different browser settings.
For the first test case, you are requesting a font-family and I’m not surprised about the substitution, given the link posted by Nicholas above.
I have a font called exactly ‘Helvetica’ on my Windows 7 PC, it’s an old PostScript version, I’ve never found a better version to replace it. If it happens to get enabled then the web gets to be a mess. Pretty much any page written with Mac in mind becomes tough to read.
I ran a quick test with the Helvetial page and got a very mixed set of results:
URL of image: https://docs.google.com/file/d/0B0_Jj1eMQFxhRERxaWpDSjd0dkU/edit?usp=sharing
Is there any issue stemming from the use of ID selectors starting with a numeric character instead of an alpha?
Philippe, I don’t actually have a font called “Helvetica” (of any variety) installed in my Windows VMs either. However, if the font family name “Helvetica” is recognized (and substituted) in the first test, it seems reasonable that the same would happen in the second test. After all, if Helvetica == Arial then H == Helvetica == Arial, surely?
Bob, that’s just awe-inspiring, very much in the original sense of the term. Thanks for compiling and sharing it!
Justin, IDs are still spec-required to start with a letter, but since I’m not starting IDs with numeric characters in the test, it shouldn’t have any effect.
Eric,
I wouldn’t expect so. With
src:local()you area asking for a very specific font-face – a file that must exist on the local system. At least my expectation in that case is that no substitution should happen. On the other hand, if the alias works at the file level (as opposed to ‘family name’ level, the way I understand it, I didn’t really find any documentation on this, probably using the wrong keywords in$search-engine), then you’re probably right andH === Arial– or should be. But I’m certainly no authority on the inner working of the Windows font-system. And to make matters more complicated, there are differences between the ‘old’ GDI (what Chrome uses) and the new fanged DirectWrite (Win7, IE 9 and Firefox).