meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Helvetial

Maybe 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.

14 Responses»

    • #1
    • Comment
    • Tue 12 Mar 2013
    • 1708
    Peter Foti wrote in to say...

    For me the results are:
    Chrome: It all looks the same.
    Firefox 19: #102 .s01 looks different, the other 3 look the same

    • #2
    • Comment
    • Tue 12 Mar 2013
    • 1712
    maxw3st wrote in to say...

    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.

    • #3
    • Comment
    • Tue 12 Mar 2013
    • 1724
    Eric Meyer wrote in to say...

    I updated the test (and the post) to lock things down as much as possible—adding a serif font to the body, and replacing fantasy with monospace. Force-reloads may be necessary.

    • #4
    • Comment
    • Tue 12 Mar 2013
    • 1812
    Matt wrote in to say...

    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.

    • #5
    • Comment
    • Tue 12 Mar 2013
    • 2039
    Eric Meyer wrote in to say...

    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.

    • #6
    • Comment
    • Tue 12 Mar 2013
    • 2134
    Nicholas Piasecki wrote in to say...

    [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.

    • #7
    • Comment
    • Tue 12 Mar 2013
    • 2146
    Matt wrote in to say...

    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.

    • #8
    • Comment
    • Tue 12 Mar 2013
    • 2205
    jeremy wrote in to say...

    For what it’s worth, for me – in Chromium on Linux, the two lines look exactly the same.

    • #9
    • Comment
    • Tue 12 Mar 2013
    • 2209
    Eric Meyer wrote in to say...

    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…)

    • #10
    • Comment
    • Wed 13 Mar 2013
    • 0051
    Philippe wrote in to say...

    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.

    • #11
    • Comment
    • Wed 13 Mar 2013
    • 0645
    Bob Janes wrote in to say...

    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

    • #12
    • Comment
    • Wed 13 Mar 2013
    • 1320
    Justin wrote in to say...

    Is there any issue stemming from the use of ID selectors starting with a numeric character instead of an alpha?

    • #13
    • Comment
    • Wed 13 Mar 2013
    • 1332
    Eric Meyer wrote in to say...

    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.

    • #14
    • Comment
    • Thu 14 Mar 2013
    • 0233
    Philippe wrote in to say...

    Eric,

    After all, if Helvetica == Arial then H == Helvetica == Arial, surely

    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 and H === 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).

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


March 2013
SMTWTFS
February April
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Sidestep

Feeds

Extras