My love of typography originated in the 80′s with the golden years of 8-bit home computing and their 8×8 pixel monospaced fonts on low-resolution displays.
It’s quite easy to find bitmap copies of these fonts and also scalable traced TTF versions but there’s very little discussion about the fonts themselves. Let’s remedy that by firing up some emulators and investigating the glyphs.
Atari’s entry into the home computing market put out some very capable machines with all sorts of hardware tricks (the creative geniuses behind it would go on to form Amiga). The same font was used on all Atari 8-bit models from the original 400/800 to the XL and XE models in the late 80′s.
6 pixels uppercase causes some vertical imbalance especially on ’9′
Braces are overly bold being 3 pixels wide.
Less than and greater than symbols are too tall.
‘MWw’ make great use of width to nice effect
Bar on ‘G’ too low, ‘U’ overtly square, ‘X’ very blocky, ‘S’ does not extend enough
The machine boots in a low-contrast blue-on-blue and is designed for use with TV’s which explains some of the odd characteristics above like the square U to distinguish it from the V. It is likely the 6-pixel choice is to allow the letters to be centered when using inverse letter mode.
One byte per row, 8 sequential bytes making one glyph. You can reprogram this by poking address 756 with the page number of the new font (default of 226 for ROM location 0xE000).
The Beeb, as it was affectionately known, has its own font which could display in three different modes – one wider and one narrower but many users might not recognize it all as it booted into ‘Mode 7′ utilizing a Videotex chip (used in the UK for text-on-TV and travel agents as well as in France for Minitel) that had a different font of its own.
Drops bold in tight spaces e.g ‘$&@’
Outlines the tail on the ‘Q’ to make it much clearer
Unique and beautiful ‘*’
Does not extend low bar on ‘e’ as much as expected and ‘f’ seems to wide
Vertically squished ‘?’
Style of single-quote ‘ is inconsistent with comma
The machine generally shipped with good quality monitors and the combination of high-contrast colors and this bold font made it very readable indeed.
It’s quite likely it was influenced by the Atari 8-bit font but with larger capitals and ascenders and a much more consistent look.
The system font is stored at 0xC00-0xC2FF with each character being represented by 8 sequential bytes (left pixel is high bit).
You can replace the font used by system text routine OSWRCH (0xFFEE) using the VDU command 23 followed by the ascii code and then 8 rows of data, e.g.
Sinclair’s successor to the ZX81 added color and lower-case letters – again preserving the upper-case and numbers from it’s predecessor but finally mapping them to ASCII. This font was re-used on Jupiter Ace and Timex machines but the ZX Spectrum was the most popular.
6 pixels uppercase leaves many unevenly balanced ‘BEFS’ and ‘X’ with ugly 2×2 center
Full stop is 2×2 pixels (bold) but colon, semi-colon and comma are not
Capital ‘MW’ are very slight with latter hard to distinguish from ‘V’
Uneven styling ‘c’ omits curves, ‘e’ is soft ‘g’ is not, ‘f’ and ‘k’ are thin
Only the copyright symbol uses to the top row of pixels
While the machine has a default high-contrast scheme the video output was poor because of the quality of the RF modulator and home TVs it was connected to. It looks like the designer decided to increase spacing between letters after the ZX80 from one to two pixels which greatly limited what could be done with the letters themselves. This was likely done for the same reasons it was done on the Atari 8-bit – namely to allow the letters to be centered when using inverse text modes.
Sinclair ZX81 (no lower case), ZX80 (7 pixels wide).
The system font is stored at 0x3D00-0x3FFF with each character being represented by 8 sequential bytes (left pixel is high bit). You can replace the system text routine (RST 10) by poking the new fonts memory address into the system memory map at 23606/23607 minus 256 bytes (the first 32 characters are non-printable, 32×8 = 256)
Commodore took to take their success with the PET and applied it to the home first with the VIC 20 and then later with the wildly successful Commodore 64.
Inconsistent shapes/style across ’147,&<>@Q’
2×2 pixel of ‘.’ is not carried through to ‘;:!’
Ascenders not as tall as capital letters
The bold font was essential for the low-quality TV’s Commodore were aiming at. The inconsistencies across the font may have been intentional to help make the letters look different (A vs 4, 1 vs I, 7 vs T) given the limitations of the displays or just poorly implemented (see below).
Lower-case is identical to the Atari 8-bit font and likely copied wholesale as they do not match the upper-case well. Symbols, numbers and upper-case are a bolded version of the PET font that looses the serifs and also could explain the odd reproductions of 1, 2, 7 & 4.
Alan Sugar’s foray into the UK market came a little later than the other 8-bits in 1984 with the Amstrad CPC series.
Full use of 7 pixels for upper and 1 pixel for lower means glyphs can touch
Serif choice is unusual and not consistently applied because of space constraints
’0′ is wider than would be expected (copied from
Very distinctive curves on ‘CGOQ’
‘X’ looks like a different style because of high mid-point
Sugar wanted the machine to look more professional than other home computers at the time. The choice of a serif based font to look like PCs which also featured serifs (at a higher resolution) reflects that desire.
Very similar to the IBM CGA font with some adjustments (fixes) to the horizontal positioning of some symbols. Many characters completely identical and some bearing style similarities too (wider 0, X choosing one side to be longer than the other). Some other characters bear similarity to the BBC Micro (Q uses the same trick to keep it distinguished) and a number of symbols and lower-case letters being the same where serifs would not fit.
The Amstrad CPC manual shows the system font but is different in some areas. It is possible it is a transcription problem (z is shifted up one pixel, missing pixels on ’37PRz~’ and extra pixels on ‘#b’ ) although it could have been an earlier version from the designer as ‘rG?’ are subtly different.
Redefine using the Amstrad BASIC command SYMBOL that takes an ascii code and then 8 comma-separated values one-per-row in much the same way as the BBC with the VDU 23 command. SYMBOL AFTER must be set first e.g.
SYMBOL AFTER 32
Regular condensed sans
320×200? (40×25 text)
Microsoft? Download in TrueType
The MSX differs from the other machines here in that it was a standard rather than a specific machine. It was very popular in Japan and did hit UK shores although I only knew a single person that had one apart from our school which had acquired several Yamaha models to control MIDI keyboards. Given the multiple manufacturers it’s not surprising that some models had slightly tweaked fonts but the one shown here seems to be the most popular.
Full use of 7 pixels for upper and 1 pixel for lower means glyphs can touch
Only 5 pixels wide for the letters
Pixels touching on the curves of ‘db’ etc. look quite ugly
Very angular curves on ’5′
An unusual choice that feels very quirky.
Most likely influenced by the Apple ][e.
Mac users should try Cathode – a retro terminal emulator I helped add some of these fonts to.
Taking my bitmap font Envy Code B into the vector TrueType Envy Code R was a long process, the most difficult being hinting.
Bitmap v scalable fonts
Bitmap fonts are incredibly easy to make. Using a program like Softy or BitFonter you decide the size of your letters and start plotting pixels. You can see exactly how it will look because you draw every glyph (letter/symbol/number) in every size you want to support. This can obviously be very time consuming and doesn’t let you take full advantage of the resolution of the device and the capabilities it offers. A printer can handle in excess of 300 dpi while a display is typically 72 dpi (Mac) or 96 dpi (Windows) with LCD’s supporting sub-pixels due to the individual layout of the red-green and blue elements you can’t feasibly pre-plot every single combination and even if you could the file size would be rather large.
Rather than having specific set of pixels to turn on or off TrueType, OpenType and PostScript fonts contain a series of instructions that tell the computer the shape using a series of points, lines and curves. This means the computer can scale the glyph to the size that is required and then take full advantage of the device being rendered honoring the users preferences for anti-aliasing (smoothing using shades of grey), sub-pixel precision (smoothing using hints of red, green and blue to take advantage of the layout of colour elements in an LCD display), desired contrast and gamma settings etc.
Such a scaled glyph won’t fit perfectly within a pixel grid and a small sizes and low resolution it can look awful. It is also necessary to ensure that the vertical part of the letter I (known as a stem) looks very similar to the stem of other letters at the same size – we don’t want some letters looking bold – and that the top of the letter o aligns nicely with the top of the i etc. (in most fonts). The glyphs themselves don’t know what is a stem, what should align with other glyphs etc.
Many renders include logic to try and improve un-hinted fonts such as the drop-out control in Windows through to the full auto-hinter in FreeType. If you’ve ever used free fonts from any of the numerous web sites around you’ve probably seen that it doesn’t get it right and it looks like this:
The first few versions of Envy Code R looked like that because to address this problem you need to learn a process called hinting, which let’s the designer give the renderer “hints” on how to choose the pixels.
Font hinting started off as stem and edge identification so that glyphs would maintain the right proportions when sized and rendered on these low-DPI devices. It became apparent that a much more fine-grained level of control was required and so a stack-based byte-code language was developed as part of the TrueType specification to allow designers finer control in how points are adjusted to better take advantage of the display characteristics.
A TrueType font can contain extra blocks which describes, using a sequence of bytes that represent instructions and their arguments, the process by which to align the points and therefore make decisions about how best to fit the letter into the grid by retaining and adjusting various elements.
The important blocks are:
Run once when font first used to setup the tables.
Grid-fitting and scan conversion
Table specifying when to apply smoothing and grid-fitting based on size ranges.
Control value program
Run every time the font needs to be drawn differently (e.g. change of size, changing anti-aliasing etc)
Control value table
Set of tables that can be used to specify various heights, widths, spacing, positions etc. that glyphs can relate to.
Each instruction (opcode) has a mnemonic that is representative of what it does and these are documented in Chapters 5 through 6 of the TrueType specification (along with much other useful relevant information). Actual per-glyph instructions are stored with each glyph outline in the glyp block.
Windows – User choice of 1-bit, 4-bit grey-scale anti-aliasing, ClearType, ClearType tuning and display DPI plus WPF and DirectWrite per-app options
Mac OS X – User choice of sub-pixel anti-aliasing strength and 1-bit cut-off plus per-app 1-bit option (e.g. Terminal)
Java – Per-application choice of 1-bit, grey-scale or sub-pixel rendering
Flash – Per-application choice of 1-bit or grey-scale
FreeType – Rendering library that exposes a number of runtime and compile-time settings
This is of course ignoring the other rendering engines out there such as the Adobe’s Photoshop, RiscOS, D-Type rendering engine, Font Fusion (used on BeOS) etc. and prior versions of those renderers listed above (Flash and Mac OS changed significantly). Getting it pixel-perfect on every combination is impossible but we can try :)
Instructing fonts is a painstaking process at the best of times and few people deal directly with the low-level instructions instead relying on tools, stem identification and higher-level languages to achieve the same result. Some tools that have support for hinting instructions are:
FontLab Studio 5 Comprehensive font-production package for Windows and Mac that includes auto-hinting and it’s own higher-level link language that it can generate TrueType instructions from but it does not support viewing or modifying existing TrueType instructions and does not handle diagonals well. Rendering preview includes mono, grey-scale and ClearType. (Commercial $649)
Fontographer 4.1 Rather dated font-production package for Windows and Mac. (Commercial $349)
FontForge Comprehensive font-production package that runs on X11 that includes auto-hinting and the ability to disassemble and edit existing TrueType instructions as well as debug them with stepping. Includes basic mono/grey-scale rendering options. (Open source)
Microsoft Visual TrueType Hinting instruction tool from Microsoft that uses it’s own higher-level VTT Talk language that compiles down to TrueType instructions that you can further edit. Includes a comprehensive set of preview rendering options but is not capable of disassembling existing instructions. (Commercial, free with signed licence agreement)
TTX Python scripts that can convert a font into an editable XML representation and back including disassembly and assembly of TrueType hinting instructions. (BSD)
TTIComp Command-line tool that provides an alternative C-like hinting language. (GPL)
Xgridfit FontForge scripts to provide an alternative XML-based hinting language. (GPL)
TrueTypeViewer Windows tool for displaying TrueType fonts and glyphs including debugging and descriptive disassembly of instructions. (GPL)
TTHMachine Real-time editing of hinting instruction mnemonics and observing their effects which is useful for learning. (Free, no longer supported)
Computing history tells us of a mythical place where many of the innovations we take for granted today were either invented or refined to a working level at a single location known as the Xerox’s Palo-Alto Research Center (PARC).
These discoveries form the basis of much of the technology we use today and include the desktop metaphor, the graphical user interface, laser printers, object orientation and Ethernet.
Xerox manufactured a number of high-end machines including the 1973 Xerox Alto which, being GUI based, shipped with a number of proportional bitmapped fonts.
What is interesting to me however is the mono-spaced font used by the SWAT debugger (but not by the command prompts, they were proportional – ahead of their time!) and so, based on a screen-shot of SWAT, I thought it needed to live again!
I’ve had to make up a few of the symbols and letters that weren’t shown and filled out the symbols for the Windows 1252 Latin-1/ISO-8990-1 code-page and with the absence of any solid information online give it a name so here is Alto Mono!
When using the TrueType version choose 6 point on Windows and 8 point on Mac OS X.
The Xerox manuals are also fun to browse though with such section headings as “Things the user doesn’t really need to know…” and “How to get out of trouble” and the comments about SWAT’s odd syntax and interface.
Don’t forget to check out my reproduction of the PalmOS system font. Not monospaced but very clear at small sizes – great for the Visual Studio output window ;-)
It’s been a struggle but finally after countless hours here it is, the next release of my Envy Code R monospaced (fixed-width) font designed for programmers.
Many glyphs have been redrawn since preview #6 including braces, lower-case y, 6 & 9, ampersand, dollar-sign, hash etc. One pixel was removed vertically height to make the box drawing balanced and allow more lines per screen.
These new box-drawing, shading and symbols make Envy Code R a great font for the command-prompt (Consolas and Lucida Console lack box-drawing completely). To use them you will need to run the included registry file and reboot to operate correctly from a command prompt’s properties dialog.
This typeface contains over 550 glyphs providing full complements for DOS, Windows and Mac versions of the US, Western, Central Europe, Turkish, Baltic, Icelandic and Nordic code-pages. This hits several Unicode ranges including Basic Latin, Latin-1 Supplement, Latin Extended A & B, Box Drawing, Block Elements, Letterlike Symbols, Number Forms, Arrows… although not all of these ranges are complete yet.
As well as regular and bold variants this version includes a full italic version too and the obligatory italic-as-bold hack to get italic syntax highlighting in Visual Studio as shown here in my favourite 10 point with my Humane theme.
And for those of you that like the font a little larger it now looks good and the odd sizing issues are all gone!
Okay, enough with the teasing, you’ve waited far too long…