Now let’s go into a bit more detail about proportion and aspect ratio. An aspect ratio is, at least when we’re talking about displays, the ratio of the width to the height of an image. In Part 1 of this series I talked about how the default CMD.EXE font was totally the wrong size. The end result of this being that the storage aspect ratio was also totally wrong, resulting in proportions being completely different than originally intended by the artist.

Simply put, the 8 x 12px font has the same width as the 8 x 16px, which has to mean its proportions must be different. Let’s take a look at the numbers for a better understanding of why that is. The 8 x 16px font, the width being half the size of the height, has a .5:1 (or 1:2) aspect ratio. The default Windows CMD.EXE 8 x 12px font has an aspect ratio of ~.67:1. Quite different. To have the same proportions, it’d need to be 6 x 12px, which would give it the same .5:1 aspect ratio. For the record, the original 9 x 16px font has an aspect ratio of ~.56:1, which means its actually somewhere in between. If you compare the three images of ACIDDraw I used as example in Part 1, you’ll see they’re all the same width, but with very different heights and, therefore, proportions. Here’s a more direct comparison for the visually oriented, keeping in mind the 9px wide font has been resized to have the same width as the other two:

So which one of them is accurate? Well, talking strictly from an artistic standpoint, whichever one the artist drew it with and/or intended for it to be viewed with. These days, that probably means 8 x 16 but it could easily be any of those. In this case, while its been awhile, I’m pretty sure when I drew that outline I was using the 8 x 16 font. Thanks to more and more modern ANSI editing and viewing applications saving this information in SAUCE meta data and referencing it when rendering, a lot of times it’ll actually be displayed as intended, but that really only goes for much newer art displayed by much newer applications, unfortunately.

Now it’s time to throw a massive wrench into the works. You see, when talking less modern applications, well, none of these are accurate.

The VGA graphics mode that most IBM compatible PCs were using with the now discussed-to-death 9 x 16px font for text mode was running at 720 × 400 screen resolution. Interestingly enough, unlike most of the other screen resolutions we’re used to dealing with these days, 720 x 400 is not a 16:10 storage aspect ratio, but rather 9:5. Weird. That doesn’t really matter though – most EGA and VGA games in MS-DOS were running at 320 x 200 which was indeed a 16:10 storage aspect ratio and they’re still affected by the same issue I’m about to describe. Some of you are probably already honing in on the issue based on the subtext here. That is, none of us had 16:10 widescreen monitors back in the day, now did we? No, we had 4:3 display aspect ratio CRT monitors.

As it turns out, there is a difference between our storage aspect ratio and display aspect ratio, so our pixel aspect ratio isn’t 1:1. Due to their analog, raster scan nature, our old CRT monitors would actually stretch square pixels to be quite a bit taller than they are wide. The stretch from 16:10 to 4:3 is fairly dramatic, as it’ll take little imagination for most of us to recognize since it hasn’t been that long since we moved from 4:3 or 5:4 monitors and TVs to 16:9 and 16:10 widescreen monitors and TVs. What that means is that in addition to needing to use a font that is yet taller than it is wide than the one Windows wants us to use by default, we still need to stretch the entire image vertically by something like 35% to make it look how it would have looked when we were drawing it using something like ACIDDraw or TheDraw back in the day. Here’s a nice video discussing this phenomena as it applies to DOS games, with loads of examples.

Back in the world of text mode, here’s an example of taking the above image with the correct 9 x 16px font in its native 9:5 storage aspect ratio and stretching it to a 4:3 display aspect ratio in an image editor to simulate how it would look on a CRT:

That’s a big difference! I drew that outline without using the stretched aspect ratio so that’s not necessarily “correct” in this case, but the vast majority of ANSI art before the mid 2000s would have probably been drawn in 4:3.

Unfortunately fixing this is way more complicated than changing a font around, and is best accomplished with some form of video manipulation. A lot of retro game emulators, for instance, include some sort of a way to approximate this stretched out display, but unfortunately very few text mode programs I’ve encountered seem to be concerned or even aware that this is a thing. PabloDraw and its short-lived competitor TundraDraw, include an option to emulate this video stretching, meaning ANSI and ASCII fans and artists can still view and draw today using this display aspect ratio if they choose. Sadly, none of the most popular ANSI-BBS compatible telnet and SSH terminals out there that I’m aware of (such as SyncTERM or NetRunner) support any sort of 4:3 aspect ratio emulation. As for CMD.EXE itself? Nope!

So, short of dragging your old CRT monitor out of your attic and plugging it in, then forcing CMD.EXE and the rest of your console applications to run full screen (which doesn’t even appear to work in Windows 10’s new CMD.EXE by the way) there aren’t many workarounds to this issue. DOSBox is a good way of running old DOS programs with an emulated 4:3 display, though you’ll need to tweak the default settings to achieve this. Even still, since DOSBox is developed primarily with running old games in mind, not all old BBS scene related programs will run correctly under it. Perhaps setting it up to dial out to telnet boards would be a good subject for a future article, though! For CMD.EXE and 32 or 64 bit console applications, it seems that sticking with that old trusty 8 x 16px font may be a decent compromise, as it produces a display aspect ratio just a little bit closer to the full 4:3 height than the 9 x 16px font does.

Thankfully, at least viewing standalone ANSI with the correct fonts and aspect ratios is much easier. Besides being supported in PabloDraw, as mentioned, virtually all of the online text mode art viewing sites (such as 16colo.rs) are using the brilliant Ansilove utility to do their image conversion. Ansilove supports both the 9px wide font and, as of this year, the ability to stretch the display aspect ratio as well, meaning modern efforts to display and archive text mode artwork will have a leg up on accuracy.

Well, I didn’t say it was all good news. On to something a little easier to tackle…

—
1. ViiX2 – XXX – We Hijacked!.ans by Jack Phlash, Enzo, and Avenging Angel from Vii-X2 #2 (2005)

During a recent chat, a prominent ANSI artist mentioned his concerns about the way his ANSI was being displayed in a screenshot I sent him. This lead me down a bit of a rabbit hole of thinking of how people use the CMD.EXE console, first introduced in Windows NT and still with us today, in a bit of mutated form, in Windows 10. To make one exceedingly broad, overarching statement here, it’s important to start by acknowledging that CMD.EXE is absolutely not MS-DOS, so these tweaks are just the tip of the iceberg, especially getting beyond basic aesthetics. Still for those of us who occasionally use the “command prompt” in Windows to run 32 bit console applications (or if you’re using 32 bit Windows, even old 16 bit DOS programs) things just aren’t quite right.

First there’s the font. ANSI artists reading this are probably passingly familiar with the disparity between using a normal 8px wide font vs the old 9px wide VGA font since it’s, if nothing else, right there in the menu of our most popular modern ANSI editing tool, PabloDraw. Even back in the DOS days the 9px wide font was a bizarre thing artists had to work around, or sometimes take advantage of to interesting effect. Suffice to say, most of us have gotten used to drawing and viewing ANSI in the 8px font these days and may even prefer it. So what then, do we make of the bizarrely squashed font we encounter when running CMD.EXE? It can be kind of jarring, that’s for sure. Probably a lot of us would assume that it has something to do with the difference in aspect ratios, which is partially correct, but not for the reasons you might assume. I’ll talk about more in Part 2. The biggest problem is actually that Microsoft defaulted the CMD.EXE font in all versions of Windows up until Windows 10 to a 12px tall font. The original VGA text mode font most of us PC types are familiar with is 16px tall. Yes, that is a big difference!

Allow me to demonstrate via Windows XP’s CMD.EXE, looking at an ANSI loaded up in ACIDDraw:

This looks okay, pretty good even, at a glance. If you drew that picture, however? Especially if you might have struggled to get the proportions just right in the first place? It’s terribly, freakishly squashed! Just compare it with how it looks with a 8 x 16px font:

You’re on board, aren’t you? So let’s fix this! When you go to the properties of a running CMD.EXE you’ll see a handy tab labeled “Font”. Therein is a list of TrueType fonts which, when clicked, allows you to pick a font size. There’s also a “Raster Fonts” section which when clicked will show you a number of bitmap font options listed by pixel sizes, including the default we’re currently using, 8 x 12. So, easy to solve right? We just change to the size we want, or maybe pick a better TrueType font and… err. I’m sure almost everyone reading this had made it this far on their own at some point in the distant past, only to discover that there isn’t any better looking raster font and the TrueType font list is missing almost all of the fonts you have installed on your system. How helpful. It’s at this point most of us would give up and resign to a life of living with these new, weird proportions.

It doesn’t have to be so! I won’t re-write the book as how to add “custom fonts” to your CMD console since it’s well documented all over the Internet. Google if you need more help than I give you here. In short, there are two basic ways to do this:

1. Install one or more 8 x 16 raster fonts. These will automatically appear in the CMD.EXE raster font list (only listed by their pixel size) after being re-launched.
2. Install one or more properly proportioned TrueType fonts. Unfortunately this method also involves having to go to “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont” in your registry and adding a new string value representing the name of the new font. Still, after that one tiny change, it should appear in your CMD.EXE’s font list after relaunching it.

Using a raster font is easier, but the advantage of using a TrueType font is that you can then use the “font size” to scale the font (well, the whole window) to a larger size.

Some of the more astute readers might have noticed that the proportions still wouldn’t be exactly correct, since 8 x 16 has a slightly different aspect ratio than 9 x 16. Again, Part 2 is going to be all about aspect ratios. Still, the short response to that concern is that you can actually install a 9 x 16px font the same way we installed the 8 x 16px font above if you really want to re-live the old days or are just a stickler for accuracy.

Of course, there’s the matter of which fonts to actually use. There are a number of good monospaced fonts that look pretty appropriate (or at least, pretty cool) and some even include the high ASCII characters needed for displaying ANSI art fairly accurately. Personally, I’m using the ones included in The Ultimate Oldschool PC Font Pack. This includes fonts from a number of old PC BIOSes lovingly converted to CP437 raster and TrueType fonts. The ones you probably want to install being “IBM VGA8” and “IBM VGA9”. Check out the awesome documentation for the font pack over here for a lot more technical details on the included fonts and some of the topics discussed here.

Definitely an improvement, right? Right. So now your text mode programs all have the right font and the right proportions! Err, not so fast!

—
1. tk-disto.ans by The Knight and Filth from Fuel #12 (1997)