Why do some font names begin with an at-sign?


It was a simple question.

For some reason, my font selection dialog (CFont­Dialog) shows a bunch of font names beginning with the at-sign (@). These fonts don't work correctly if I use them. Any idea what they are? (I tried searching the Internet, but search engines don't seem to let you search for @ so it's hard to make much headway.)

(And that's why I wrote "at-sign" in the subject instead of using the @ character.)

Fonts which begin with an @-sign are vertically-oriented fonts. They are used in languages like Chinese, Japanese, and (less often) Korean. The idea is that if you want to generate vertical text, you start with the horizontal version of the font and compose your document, then switch to the vertical version for printing.

 x x x 

I wasn't able to detect that your browser supports the @SimSun font, so I'll give an example with fake Chinese characters. Pretend that the shapes and Latin letters are actually Chinese characters. First, you compose your document with the horizontal font:

▴❤❦Quo123▴‌̥ 

When it's time to print, switch to the vertical version of the font.

◀❥❧℺ᴝᴑ123◀°

Hm, it looks like the Chinese characters got rotated 90° to the left, so they're all lying on their side. The result is not really all that readable, but wait, here's the trick: After the paper comes out of the printer, rotate the paper right 90°:

◀❥❧℺ᴝᴑ123◀°

Notice that the vertical version of a font does not simply rotate every character 90°. Non-CJK characters typically remain in their original orientation (which means that when you turn the paper, they will come out rotated). And some CJK characters change form between horizontal and vertical variants, like the period in the example above, so it's not a simple rule like "rotate all CJK characters and leave non-CJK characters alone."

This is basically a hack to get rudimentary vertical font support in software that doesn't support vertical text natively. (Web browsers support vertical text natively with the proposed writing-mode property.)

If you don't want vertical fonts to show up in your font dialog, pass the CF_NO­VERT­FONTS flag. Of course, if you pass that flag, then your users won't be able to use the vertical-font trick any more.

Supplemental reading which served as the source material for this article:

Bonus head-to-head competition: You can read how Michael Kaplan blogged this exact same subject in his own Kaplanesque way.

Comments (21)
  1. laonianren says:

    If you try this on Windows 7, you'll probably find that the @ fonts aren't listed because fonts that target other locales are hidden by default.  There's an option in Control Panel to show them, or you can pass CF_INACTIVEFONTS to ChooseFont.

  2. Joshua Ganes says:

    What do I need to install or configure to view your example? Both lines look identical to me.

  3. henderson101 says:

    This article worked in Chrome, but the RSS version via Google Reader was curiously FUBAR in Chrome. Example 1 worked. example 2 worked and the characters were on the wrong horizontal as desired. Example 3 was the correct orientation but with all the characters in the same orientation as example 2 (so in a column, but sideways) and the last 2 were just random ASCII. IE9 just didn't bother and gave the "can't detect "garbage" (this is win 7, so I'm guessing the first poster's observation is true..)

    What I take away from this? Character encoding is a real PITA!!

  4. Dan Bugglin says:

    Chrome does not appear to rotate the characters, just the whole line.  The two characters are rotated 90 degrees from each other and the vertical line is simply rotated 90 degrees.

    @henderson Google Reader blocks JS in RSS feeds (potential security breach if it did not) so that is why it was probably broken.

  5. @Joshua says:

    For suported browsers (for me, its IE8), Raimond gives an example with real chinese characters. For other browsers (for me, its Firefox 14.0.1), he gives an example with some pseudo-graphic characters, and this is also displayed in the three different ways (i.e. correct) in Firefox.

  6. James says:

    Nice example, worked perfectly in IE9/Win7 x64 with SimSun and @SimSun fonts.

    With FF 14.0.1 as mentioned above, works but with Wingdings-type characters.

  7. Miff says:

    Hmm, trying this with what's on my PC and it works perfectly in IE9, Chrome, and Opera.

    It's done via inline SVG so errors in Google Reader, etc. are likely due to the platform stripping out the svg tags.

  8. Skyborne says:

    @JamesJohnston, Office is a hipster.  "I had a ribbon UI before it was cool."  "I use a custom font control.  You've probably never heard of it."  If anything comes out for mainstream use, Office ignores it.

  9. tsrblke says:

    OK, I gotta confess, the contextual browser sniffing post that changes the example is pretty cool (athough the Q gets scrambled in the RSS feed.)

  10. Gabe says:

    Wow, I never noticed those @ fonts before because the non-Latin fonts are all hidden. A quick count shows that around 100 fonts on my system are hidden (almost half)!

    I'm surprised, though, that the @ is a prefix to the font name. It's handy to be able to see all the vertical fonts grouped together, I suppose, but I think it would be better to put the @ as a suffix. That way you could easily see if a font has a vertical variety, you could quickly switch between the two (because they're adjacent to each other in the font list), and you wouldn't have dozens of vertical fonts (32 for me) to scroll through to get to all the horizontal fonts (which you'll likely use more often).

  11. "I think it would be better to put the @ as a suffix. That way you could easily see if a font has a vertical variety, you could quickly switch between the two (because they're adjacent to each other in the font list)"

    I don't think so.  How are you supposed to see the @ suffix if you are viewing the font name in a space-constrained text box, combo box, or list box?  For example, suppose the width of the control is so low that the end of the font name is truncated.  You'll never know the suffix, and unless you know how the "@" fonts are sorted relative to the normal fonts, you'll never know which font you're picking.

    Better to implement your own sorting algorithm for the fonts that moves the ones with the @ prefix adjacent to the normal fonts.

  12. xpclient says:

    Wow didn't know this. Cool feature about printing.

  13. Gabe says:

    JamesJohnston: Generally speaking, suffixes are already used to distinguish between two similar fonts ("@MingLiU_HKSCS" vs. "@MingLiU_HKSCS-ExtB"), so the problem of fixed-width text boxes is nothing new.

    As for sorting, how do you implement your own sorting algorithm in Word or any of the innumerable programs that use the common font dialog?

  14. Anonymous Coward says:

    hack to get rudimentary vertical font support in software that doesn't support vertical text

    Actually, from what I can find on MSDN, for example at msdn.microsoft.com/…/cc194859.aspx, this is the standard way of implementing vertical text support: prefix the font name with @ and rotate it.

  15. Wow, this is timely – given that I was recently trying to come up with a sensible font name drop-down combo box in my application.  I had no idea what those "@" fonts were, but they were cluttering up my list of fonts.  A quick search revealed what they were, so I excluded them.  Thanks to your illustrated examples, I now have a *much* clearer idea of what they are and when they might be used – and realize that excluding them was the correct decision in my application until we can provide more explicit support – if it's ever requested.  It might be stupidly obvious to a computer user from Asia – but I never learned it.

    The algorithm I used to filter out vertical fonts returned by EnumFontFamiliesEx was to just check for a leading "@" character.  Is this the correct way to do it, or is there some API or flag somewhere that I missed to detect if it is a vertical or horizontal font?

    Also, Windows 7 added a new feature in the Fonts control panel icon, where fonts not in the current locale can be hidden.  For English-only speakers like me, it could be a nice way of hiding all those fonts I don't care about, like that SimSun font.  Can you smack with a clue bat the person who decided that the only sanctioned ways to use this feature would be via the font common dialog or the Windows 7 ribbon control?  Why didn't they do something like add a flag to the EnumFontFamiliesEx function that wouldn't return hidden fonts?  Instead, to quote MSDN:  "In Windows 7, there are no APIs for directly querying which fonts are hidden, or for setting fonts to be hidden."  The hidden font list works nice in built-in programs like WordPad and Paint – I can actually pick a reasonable font in those programs without wading through all the Arabic, Asian, etc. fonts.  I wish I could use it elsewhere.

    More info about this hidden font feature is here, and the problems with it: stackoverflow.com/…/too-many-fonts-when-enumerating-with-enumfontfamiliesex-function

    Note that Word 2010 (and I assume the upcoming Word 2013) use a proprietary MS Office ribbon control with lots of features and not the more limited Windows 7 ribbon.  That means their font list can't be filtered, either – because there isn't an API to get the list of hidden fonts…  It is most amusing that, by design, Microsoft's flagship Office suite is not compatible with the Windows 7 Font Control Panel – the list of fonts in Word 2010 is long and annoying.  And these are the two big cash cow products for Microsoft.  Did it never occur to anyone in the entire chain of people implementing this Win7 Fonts Control Panel… "What about Office? Can we make sure that it's compatible with Office?"

  16. Chrome doesn't appear to rotate the characters, only the whole line.  The two characters are rotated 90 degrees from each other and the vertical line is simply rotated 90 degrees.  Now what?

  17. Complain to the Chrome development team because they are doing it wrong?

  18. michkap says:

    I was first, so I think maybe I win.

    Though you win on typos corrected and politeness in talking about competitive products….

  19. Alak says:

    I really need to learn some Unicode. I have noticed parenthesis get flipped when writing right-to-left too. For example:

    Hello :-), how are you?

    And the same line with an U+202E 'RIGHT-TO-LEFT OVERRIDE' character before:

    ‮Hello :-), how are you?

  20. Cesar says:

    Funny, once I enable JavaScript here (Firefox 13.0.1 on Linux) it says I have "both the SimSun and @SimSun fonts installed" (fc-list says I do not have either). The first example is horizontal, the second example is identical to the first, the third example is identical to the first but the whole line is rotated (that is, everything is on its side). All three examples have Chinese or Japanese-looking characters, so Firefox probably picked some other CJK font for both SimSun and @SimSun.

    The JavaScript-disabled example looks correct (first line horizontal, second line horizontal but most characters on their side, third line vertical with characters in the correct position).

  21. James Schend says:

    laonianren: Sony Vegas shows the @ fonts even though they're "hidden" in Windows 7, so there must be something else going on there.

Comments are closed.