Oct 312015
 

Arial Unicode MSThe last thing I wrote about font anti-aliasing was probably a little less Microsoft-related than this one, handling [Font AA in Wine on FreeBSD/Linux], but let’s still call this “round 2”. Recently, having to display symbols and asian characters in Windows Explorer a lot (yeah yeah, because of Anime), I found the font rendering quite lacking when compared to what I’m seeing on my CentOS Linux box and my FreeBSD 10 machine. While Windows’ NTFS file system supports a wide enough array of unicode code points with its UCS2-le / UTF-16 character set including [surrogates and supplementary characters], the standard font used for displaying these characters — “Tahoma” — is partly lacking.

Reason here is, that higher Unicode symbols and characters of Tahoma are not covered by Windows’ sub-pixel anti-aliasing, also known as “ClearType”. While zoomed-up screenshots don’t do sub-pixel AA any justice as the actual sub-pixel gradients can’t be visualized anymore, you’ll still see clearly what I mean. But that’s not the only problem. For certain characters the sizing and spacing are just awkward as well, worsening the situation considerably.

Now I’m not sure about Windows 8.x and 10 as I’ve removed my virtual machines, but at least Windows 7, XP and older definitely do it in an ugly way. See here:

Symbols as typically seen in Anime series' and episodes' titles as rendered by Microsoft Tahoma

Symbols as typically seen in Anime series’ and episodes’ titles as rendered by Microsoft Tahoma

And so you can see what I was complaining about when it comes to ClearType, look at this version:

Symbols as rendered by Microsoft Arial Unicode MS

Symbols as rendered by Microsoft Arial Unicode MS

Now that’s a lot better. Just what font may Arial Unicode MS be, you may ask. But let’s get to that later. First, how about some asian character comparison? Have some Katakana and some Kanji mixed in:

Katakana and Kanji characters as rendered by Microsoft Tahoma

Katakana and Kanji characters as rendered by Microsoft Tahoma

Katakana and Kanji characters as rendered by Microsoft Arial Unicode MS

Katakana and Kanji characters as rendered by Microsoft Arial Unicode MS

As said, when zooming up, ClearType or any other sub-pixel based font anti-aliasing can’t be represented properly anymore, because the brightness gradients are lost. If you’re on a CRT that might affect the native screenshots as well, to a certain degree. But still, let’s compare top-down again:

Zoomed-up symbols as rendered by Microsoft Tahoma

Zoomed-up symbols as rendered by Microsoft Tahoma

Zoomed-up symbols as rendered by Microsoft Arial Unicode MS

Zoomed-up symbols as rendered by Microsoft Arial Unicode MS

While character symmetry is still ok with Tahoma in this case (not true for all chars), you may notice that the spacing is just terrible for the musical notes, and the sizing of the notes and also the stars doesn’t quite look right either. What’s most noticeable though is the clear lack of any smoothing effect on the symbols. Let’s look at some Hiragana, Katakana and Kanji:

Hiragana, Katakana and Kanji as rendered by Microsoft Tahoma

Zoomed-up Hiragana, Katakana and Kanji as rendered by Microsoft Tahoma

Hiragana, Katakana and Kanji as rendered by Microsoft Arial Unicode MS

Zoomed-up Hiragana, Katakana and Kanji as rendered by Microsoft Arial Unicode MS

Despite the color-shifting that comes naturally with sub-pixel AA, it’s pretty clear what looks better here in my opinion. Ah yes, please note that Tahoma was actually set to 8px and Arial Unicode MS to 9px here. Despite that, we can now see that there is some loss of detail happening for the most complex Kanji characters with Arial Unicode MS. They’d still be readable, but we can’t deny that either. To do away with that you’d need bigger font sizes, preferably on a higher-dpi monitor, like say, maybe UHD instead of 1080p-1600p. Or in other words, 150-200dpi instead of 90-100dpi. Still, despite that problem on low-dpi screens, the font just looks much neater.

The main issue here is, that Tahoma is ancient. It was one of the early fonts which could cover a reasonable amount of code points from the UCS2-le character set that Windows NTs NTFS came with. TFTs and ClearType didn’t even really exist back then. And Windows doesn’t really have a lot of fonts that can render enough exotic characters to really be sufficiently multi-lingual for certain use cases, not even talking about symbols yet. If you pick a font that can’t cover the characters you’re using, all you’ll get is just a ton of empty boxes where those chars should be.

The font I used as a replacement — Microsoft Arial Unicode MS — was specifically released to tackle these issues. It’s a more modern font that covers a wide array of characters and symbols without having to surrender font anti-aliasing on XP+ either.

That font was included in certain Office versions (2000, XP, 2003) in varying versions and has also been available as a free download from Microsoft. Unfortunately, the free downloads were withdrawn, and I can’t just post the font here due to licensing issues. However, if you search for it on the web, you may find enough download sources for it. Just keep in mind, that it’s not free. If you’re on a newer version of Windows, you may have other options when it comes to choosing your font. I’m just not sure which ones… In any case, the latest version of Arial Unicode MS is 1.01, if you wanna look for it.

If you do have Arial Unicode MS, you can switch it on in your advanced appearance menu of your display properties after right-clicking on the desktop, at least on XP. The font you’ll need to change is the “Icon” one. It’s called that, because it’ll also change the font of your Desktop icons together with the file/folder pane of Windows Explorer:

Changing the icon font

Changing the icon font

After that, pick your desired Unicode-capable font and change the size to your liking, the changes will take effect immediately after confirming the change:

Our new "Icon" font is Arial Unicode MS, changed to a font size of 9px for enhanced readability

Our new “Icon” font is Arial Unicode MS, changed to a font size of 9px for enhanced readability

Of course you could also look for other, free TrueType fonts on the web which can cover enough code points to be sufficient for your needs. Maybe you can also just copy one over from some Linux or UNIX system too. It seems OpenType fonts won’t do though, the menu only allows TrueType fonts.

And that’s — amongst other things — how you make childish Anime episode titles look neat in Microsoft Windows Explorer. ;)

(It’d really be interesting if Windows 8 & 10 give you any better options out of the box…)

Dec 112014
 

FreeBSD + WineSince I’ve abandoned OpenBSD for FreeBSD in my recent attempts to actually use a ‘real’ UNIX system, and all that just because of Wine so I can use some small Windows tools I need (yeah…), I was a bit fed up with Wines’ font anti-aliasing not working. I remember having a similar problem on CentOS Linux some while back, but I can’t remember how I solved it on that OS. Thing is, I just want to document my solution here briefly, so I don’t forget it, if I have to re-do this any time soon. The problem seems to originate from the X11 render extension that is being used for compositing on X11 without any additional compositing engine like Compiz. Wines usage of the extension is actually controlled by its system registry, and the key that seems to need editing is HKEY_CURRENT_USER\Software\Wine\X11 Driver\ClientSideWithRender.

Interestingly, people suggested to switch the use of the X render extension off instead of on, but when inspecting my setup by running wine regedit, I found I didn’t even have the key, and its default is off! So what saved me was:

  1. [HKEY_CURRENT_USER\Software\Wine\X11 Driver]
  2. "ClientSideWithRender"="Y"

Setting this back to “N” is basically the same thing as just deleting the key altogether, at least with the current default configuration of my Wine version on FreeBSD, which is wine-1.6.2. See how it looks like with no anti-aliasing (click to enlarge):

Wine running its regedit on FreeBSD 10 with no font AA

Wine running its regedit on FreeBSD 10 with no font AA

And here with proper AA, again, please click to enlarge so you can see the effect applied:

Wine with proper font anti-aliasing

Wine with proper font anti-aliasing

To demonstrate the effect more prominently, let’s look at some zoomed in versions, click to enlarge again for all the glory or so:

No anti-aliased fonts here, all jagged

No anti-aliased fonts here, all jagged

And:

Wine font anti-aliasing up close, nice and smooth

Wine font anti-aliasing up close, nice and smooth

Now I heard that some people actually prefer the clearer look of jagged fonts, or they may prefer pure gray smoothing, but I actually like the look of this smoothing a lot more. This is with medium font hinting turned on in Xfce4, and it appears very smooth and nice to my eyes.

If you want to try this in case you’re offended by jagged fonts using wine, just take the following:

  1. [HKEY_CURRENT_USER\Software\Wine\X11 Driver]
  2. "ClientSideWithRender"="Y"

Save it into a file like wine-Xrender-fontAA.reg, and then import it into your wines registry database by opening a terminal, going into the directory where your reg file sits, and by running: wine regedit ./wine-Xrender-fontAA.reg. Then restart your wine application and it should work for 99% of the fonts. I’ve encountered one font in Bruce Schneiers [PasswordSafe] that wouldn’t anti-alias, ever. But it’s the same on Windows, so I’m guessing that’s ok.

Switching it off is just as easy, just edit the file, change “Y” to “N” and re-run the wine regedit command. But as I said, I’ll keep it, no more eye cancer when starting Win32 applications on FreeBSD. :)