In the last post, I examined the idea of using @font-face to embed CJK fonts with extended characters. The over(under?)whelming conclusion I’ve seen is that although it is possible, the prospect raises a number of issues — so many in fact that it is hard to justify the effort.

The Recap

To start, embedded fonts must be converted to “embedded open-type” fonts in order to work cross-browser… most converters fail on anything other than Latin characters. Fonts must be downloaded and until they are may (in Webkit, for example) not appear at all… most CJK fonts are around 3-7mb, which could easily mean a minute or more of blank text on a 3G mobile device. Embedding fonts in a web application means you are technically distributing them… very few CJK fonts have an open license due to the work involved. The bottom line: the usability/accessibility issues raised make embedding Asian fonts more akin to a technique such as using images for text — suitable for the “fluff”, but generally not advisable for content you need 100% accessible in all circumstances. Embedding an image instead of embedding a font of course has its own consequences: text doesn’t wrap, can’t appear on any background, can’t resize, and the effort required grows exponentially if you have a mutli-language site. However if you are displaying content with such requirements, you most likely shouldn’t need special fonts anyway. You have a content-heavy site that by definition should be using the most legible, standard font available.

In this entire discussion, one point I forgot to touch on is the aesthetics: how does the actual text look once it’s embedded? I’ll get into the nitty-gritty of CJK font aesthetics below, but the conclusion should already be pretty obvious: embedded fonts may or may not look better than native ones, but they’ll never be able to look as good as an image can. This only strengthens the argument above: images may be an acceptable substitute if they’re used sparsely and only for decoration. But as you’re already probably thinking, neither technique seems like a very good solution for today’s sites which need to be content-heavy, accessible, and multi-lingual. So the question (for me, anyway) becomes: What if we can get away without using either? Just how good can we get native CJK fonts to look?

The Lineup

Windows Fonts by Family
Windows Fonts by Size
Mac OSX Fonts by Family
Mac OSX Fonts by Size
Ubuntu Linux Fonts by Family
Ubuntu Linux Fonts by Size

Let’s start with a detailed lineup of the default Japanese fonts available to the each OS. For Ubuntu Linux, I’m not sure exactly which font is being used, so I just went with the standard “serif” and “sans-serif”. On other platforms I tested different browsers and verified that fonts do in fact render pixel for pixel the same across different browsers as expected. The browsers’ ability to choose which fonts to use, however, can vary depending on certain conditions. I will go into that more below.

I should also mention up front that these tests are biased toward Japanese. This is the language I am most used to, and it is easier to pick out differences in stroke order, etc., with Japanese as the base. However the point in this exercise is to distill OS and browser generalities which should be applicable to other languages as well. As to which font faces are available for Chinese and Korean across the different platforms, I’m leaving that one on the shelf for now.

Let’s also take a second to clarify the terminology because there’s a lot. bitmap or embedded bitmap refers to pixel based fonts (like those microscopic pixel fonts designers always tell you not to use). When you change the size of a bitmap font you are essentially swapping out one image for another. You can see this by looking at MS Gothic at 14px and 15px. The spacing will change, but the faces are the same, pixel for pixel, as both sizes use the same embedded bitmap font. font outlines on the other hand contain the actual geometry of the font, so they can be any size.

Typography being the be beast that it is, many techniques are employed to make fonts more legible, especially at smaller sizes. Font-hinting uses instructions to map a font to a pixel-based grid and ensures legibility. Anti-aliasing is also used to smooth hard edges. ClearType, Microsoft’s font smoothing technology, uses a special technique called subpixel rendering, which increases perceived resolution.

Additionally, in the case of Japanese/Chinese characters, font-hinting techniques are used for stroke-reduction, which reduces the number of strokes in a character to keep it looking clean at very small sizes. Bitmap fonts also have a reduced number of strokes in their smaller embedded variants.

Windows

The first thing you will notice right away about Windows is the sudden change that occurs when going to larger sizes in “Gothic” and “Mincho”. Despite being TrueType fonts, both families contain bitmap versions at lower sizes (Wikipedia suggests 9pt… for the web it appears to be 22px and lower), and use normal font outlines at higher sizes. Gothic and Mincho were the standard fonts for Japanese versions of Windows prior to Vista, but this presented a problem as none of the smoothing techniques described above can be used on bitmap fonts. To alleviate this, Microsoft created Meiryo, which was a true outlined font. Meiryo has the advantage of looking consistent across different sizes, however the anti-aliasing tends to make it a bit blurry, especially at smaller sizes. Additionally, it has a different height ratio, and tends to sit more “squat”. Meiryo was first released with Windows Vista, which was also the first OS to have ClearType turned on by default. This made the visual appearance of Vista quite a departure from previous versions of the OS.

As CJK fonts are generally monospace by definition, different versions exist to handle different spacing of Latin characters. MS Gothic keeps Latin characters at uniform widths, while MS PGothic uses standard proportional Latin fonts, and looks more natural. There is also MS PMincho, Mincho’s proportional variant. MS UI Gothic is intended for Windows UI interfaces, and is considerably “tighter” to conserve space. From Windows 7, Meiryo also introduced a tighter UI version. However, all Latin characters are proportional in both versions of Meiryo, and it seems like the idea of non-proportional text baked into the font has been dropped altogether. Most likely this decision was due to the fact that there are full-width Latin characters available to Unicode anyway, known as zen-kaku, making a separate version of the font pointless.

Just for comparison, I also included Arial Unicode MS, an international font bundled with Office (and also Mac OSX 10.5 and later, apparently), and Kozuka Gothic Pro, a fairly standard Japanese font distributed with various Adobe software. Note that neither of these fonts are in standard Windows installs. I simply threw them in for reference.

So there’s the background, but what’s the verdict? While leaving room for subjective opinion, I think there’s a few generalizations we can make. First, proportional “P” versions of fonts tend to render English text much better than their non-proportional counterparts. Also, the “UI” families tend to squish characters too closely together. Japanese OS users are no doubt used to this in their menu bars, but it looks rather odd on the web. So right there we can narrow our choices down to “MS PGothic”, “MS PMincho”, and “Meiryo”. The more difficult question is that of bitmap vs. outlined fonts. When dealing with Latin text, the verdict has been out for awhile: pixel fonts are hard to read and anti-aliasing is good. Complex kanji, however, can use all the help they can get in terms of sharpness, and there is a “crisp” quality to the bitmap fonts (especially Gothic) at smaller sizes that makes them pop. Meiryo tends to look rather blurry by comparison, and something about it tends to look a bit odd, perhaps the “squatness”, although this is less pronounced at smaller sizes. Meiryo is still a good font, however, and Japanese tend to find it easy to read.

For me, either Meiryo or MS PGothic work for standard, readable, paragraph-text style font of around 12px-16px. They are both crisp, legible, and don’t get in the way. Keep in mind, however, that Meiryo is not available in Windows XP (there’s still a lot of XP out there, too). Ironically, on Windows systems it’s the larger sizes that tend to be more troublesome. You would think that as Gothic/Mincho use font outlining at larger sizes, and that Meiryo was designed with ClearType in mind, at least one of the two would look decent. Unfortunately, though, neither get there 100%.

It turns out that the sub-pixel rendering used by ClearType can cause jagged, pixely edges on fonts at larger sizes. The technique triples the perceived resolution, but there is a caveat — the resolution is only increased horizontally. The difference can be shown by looking at an angled line. At 45 degrees, the pixel “steps” come very close together, and the human eye perceives this as a straight diagonal line. However, as the line approaches horizontal or vertical there are less steps, and the line appears more jagged. If this line used sub-pixel rendering, steep vertical lines would appear smoother because the increased horizontal resolution allows finer gradation in the “steps” of the line. However, flat gentle lines would appear jagged because there is no increase in vertical resolution.

In practice, the problem can be seen easily when looking at hiragana, which has large, sweeping strokes. The hiragana word “どうぞ” looks particularly bad. If you zoom in, however, you can see that in fact smoothing techniques are being applied, and the sharp angled “く” looks much better. Stroke thickness in kanji can also be affected by this, producing some odd-looking results. The “jagged” effect is more pronounced at larger sizes, which have longer lines with flatter curves. To contrast, try using “standard” font smoothing instead of ClearType. Traditional anti-aliasing uses semi-transparent pixels to smooth jagged edges, but on a pixel (as opposed to sub-pixel) level. ClearType’s finer resolution presumably had better results, however since both techniques (as far as I know) are mutually exclusive, long, flat lines in large fonts rendered with ClearType will still show jagginess as if no smoothing were applied at all. “Kozuka Gothic Pro” in contrast looks outstanding, presumably because ClearType is incompatible with open-type fonts. Of course as luck would have it, “Kozuka Gothic Pro” isn’t available on most systems.

Unfortunately, ClearType is on by default from Windows Vista onward. It’s here to stay, so a backup plan is required. Fortunately, the oddities in kanji stroke thickness only appear at certain sizes (32px for example is particularly bad). Simply avoiding those sizes can do a lot for improving kanji faces. Of course, keep in mind that if the user is resizing your text, the uglier glyphs may still appear. On a side note, as Internet Explorer 7+ allows text zooming, I’m more or less using pixels for my text these days without too much guilt. The web is all about pixels anyway. Of course you could just as easily apply this technique to “ems” if you knew which em sizes looked good. Remember that “ems” inherit, though, so this might quickly get out of hand. Not much can be done about the jagged edges, however. The best I can recommend is to keep the font sizes down so that the jagginess is less pronounced, and if possible avoid hiragana and other characters with large, sweeping strokes. In the spirit of optimism, it doesn’t hurt to specify a better font to use if available (like Kozuka), but don’t get too used to looking at it that way, especially when testing, as 98% of your users will probably see something else.

Mac OSX

What can I say about OSX? It has outstanding font rendering, and CJK fonts are no exception here. They are smooth, strong, legible at smaller sizes, and consistent in stroke thickness. They also don’t show the jaggy edges that Windows does at larger sizes. I also feel that the faces themselves are closer to what you see in Japanese print, while Meiryo feels like something you only see in a Windows OS enviroment. Hiragino Mincho is also a very sexy “serif-style” Japanese font, and blows MS PMincho out of the water, font smoothing or no.

Apparently some contention exists that Mac font anti-aliasing is too strong, and the text can be blurry. Allowing this viewpoint as a difference of opinion still doesn’t change the fact that the CJK fonts fit right in with other languages, as if they were part of the same UI. Compare that with Windows where, although bitmapped Gothic fonts may be crisp and readable, they stand out like a sore thumb against an anti-aliased Latin face using ClearType. Additionally, the anti-alias threshold can apparently be changed as well. If you’re in the “too blurry” camp, you’re still only a small tweak away from what seems to be perfect typographical harmony.

Hiragino Kaku Gothic Pro vs. Meiryo

For a more direct comparison, the screenshot above compares the OSX Hiragino font with Meiryo. Personal preference may prevail at smaller sizes, but Meiryo’s jaggedness gets more noticeable at larger sizes, while Hiragino still looks outstanding. Meiryo also somehow starts to look more and more “squat” the bigger the font gets. It isn’t horrible, but definitely not as natural as OSX.

Ubuntu Linux

Clearly there are many flavors of Linux out there, and each distribution probably has it’s own quirks with font rendering (such is Linux). Ubuntu specifically is notorious for it’s horrible Japanese font rendering, but looking at the latest version (10.04), these problems seem to have been addressed, and the results look quite good. The faces themselves don’t look quite as nice as Mac (hiragana/katakana, for example, don’t seem to have any notion of a difference between serif and sans-serif), but font-hinting and rendering look just as nice, and type is still very legible at small sizes. As a general rule, Linux presents less of a problem as people browsing in a Linux environment tend to perform a lot of tweaking anyway, and default fonts may in fact be overridden by the user.

Browser Quirks and Hints

Browser Font Variations

When it comes to CJK fonts, rendering and typefaces tell only half the story. There are also browser differences that will affect which face will be selected. The screenshot above shows direct comparison of different fonts with different CSS declarations applied.

First, it its important to note that sans-serif and serif are not necessarily equal to the default font, so you should always specify at least serif or sans-serif as a backup. Also, you must do this in the same “font-family” declaration, not elsewhere, otherwise the browser will use its default if the font doesn’t exist, which is probably not what you want (more on this below). More advanced browsers like Firefox tend to recognize the mapping, for example, between “serif” and “MS Mincho”, but don’t forget to add a Windows-specific font, as this behavior can’t be depended on in Internet Explorer. Chrome on Windows also shows some signs of not respecting “serif” or “sans-serif” as well, so it’s always a good bet to specify a Windows font additionally.

One important point is to add a “lang” attribute to the html elements that contain your CJK content. This will help the browser to know which faces to choose (Chinese vs. Japanese, for example) when using default fonts like “serif” or “sans-serif” that aren’t language specific.

Another quirk that may come up concerns the “font-family” CSS declaration. Although it inherits to child elements, the declaration is entirely overwritten if declared on a more specific element. Effectively, this means that if you have “Comic Sans MS” on the body, and an unknown (not installed) font on all “p” elements, the rendered font will not be Comic Sans, but the browser default. This may be obvious, but it takes on a different dimension with CJK fonts, where you may specify an overriding font for Latin text. If you have, say, “Tahoma, MS Gothic” and Tahoma is not installed, Latin text will be rendered with the (quite ugly) MS Gothic Latin default. On the other hand, if the situation was reversed and MS Gothic were not installed, you would end up with Latin text in Tahoma and hiragana, katakana, kanji, etc. rendered in whatever the browser could find. In this case the browser may make an educated guess, but there is still ambiguity to the origin of the language, which is another reason that it’s always a good idea to use the “lang” attribute for CJK when possible.

Conclusions

Getting CJK fonts to look like you want is an art. If you’re a perfectionist it can be frustrating, but if you’re willing to make a few compromises, you may be satisfied with the results. Mac OSX looks damn near perfect right off the bat. Linux is so varied, as well as specialized, that you’re pretty much limited to applying some general rules and hoping for the best. If your fonts look too horrible, there’s still a good chance that your audience is savvy enough to do something about it themselves, so there’s not so much cause for alarm. Windows requires a little fussing, and different strategies for different sizes. I’ll put the general conclusions into a do/don’t list.

Do

1. Use a proportional font like MS PGothic or Meiryo for readable, content-heavy paragraph text, 12px-16px.
2. Use other Latin-based fonts in front of your base CJK font for better looking Latin text.
3. Add a “lang” attribute where appropriate to the elements that contain your content.
4. Limit larger font sizes to pre-determined ones that you know render well.
5. Remember that family declarations don’t cascade for the same text. If you want to use Tahoma for Latin text, and MS PGothic for Japanese, they both need to be in the same CSS declaration.
6. Be an optimist and include special fonts, but always view your site in standard fonts first on the assumption that most people won’t have them, because they probably won’t.
7. Use other OS specific fonts if you like them and know they will be installed. Layering on better typography while providing fallbacks won’t hurt you.

Avoid

1. Using “serif” or “sans-serif” for CJK content without specifying a Windows specific base font ahead of it. OSX and Linux, on the other hand, can generally be trusted to do their own thing with just those two.
2. Certain sizes that you know have rendering issues for the type of content you’re trying to render.
3. Obsessing over getting large fonts to look perfect in Windows. As long as ClearType is on by default you will probably have to accept a certain amount of jaggedness and stroke thickness oddities. Try to minimize these by playing with the font size, however.

If you’re interested in performing your own font experiments, I’ve written a little helper to render fonts in different sizes, families, groupings, etc:

Font Selector

On a final note, I would really love to see something like the Google Font API get a beautiful CJK font in their font directory. My absolute favorite is “Kozuka Gothic Pro”, which is owned by Adobe, but Google has money (hint hint). The heavy caching power of Google could help to take the edge off a ~5mb font download and could potentially make font embedding a reality for Asian language content.