Type Network



TYPETR / News /

The making of Bitcount

The Bitcount project started in the late ’70s as an experiment to find the minimum amount of pixels necessary to make a full set of ASCII characters. As normal as that may seem today, it wasn’t then.

For printing typefaces where hidden deep inside commercial typesetting machines (as photo negatives, not even as digital information), or stored as bitmap in terminal screens. Resolution and speed were costly resources, so the bitmap was hardcoded into the screen electronics, often just for one side.

It was the general convention at that time, that for Latin, at least 9 pixels where necessary to make a clear distinction between capitals (7), lowercase (5), and descenders (2). Furthermore, all letters needed to be monospaced, because there was no way pixels could be stored as in a graphic screen. The shapes where generated by hardware during the drawing of scan-lines of the television screen. Proportional spacing would add a lot more costly hardware.

The design of these pixel grids was almost exclusively the domain of engineering: Take a matrix and add pixels until it can be recognized as an ’n‘.
The problem with this approach is that contrast seems like luxury not worth considering (if such a thing is was considered at all). The stems of such an ’n‘ have a width of one pixel, vertical and horizontal equally spaced. But the problem is in the diagonals. Simpel mathematics shows that if the vertical distance between pixels is 1, the diagonal distance between points is 1.41, showing as a lighter area in the letter.

This is not a problem where bows get in to stems, but on the top-right of the ’n‘ it is, because that is traditionally the darkest part of the letter shape. 
The contrast makes the difference between ’n’ and ’h’ 3 pixels, instead of the traditional one pixel. This compensates for the relative small ascender length of only one pixel.

Early sketches of the 5 x 7 pixel grid. Note the various alternatives for the ’m’, to make it fit in the impossible width of 5 pixels.

Example of an editor for type design, developed im 1980, using Ikarus curves. The type in the UI was Bitcount (then called “VijfZeven” - “FiveSeven”).

Weight variations can be made by altering the pixel size (or intensity), instead of adding more pixels. Although the 2-pixel contrast stem could be interpreted as bold, it is compensated by using very small or light pixels.

In a modern Python programming editor, the use of variations can look like this. The shape of the pixel is connected to the function of a specific word in the programming language.
Nowadays the use of small pixel fonts almost disappeared, due to the increase of screen resolution and the availability of anti-aliased type on screen.

On the other hand, designers may decide to use the vintage character of low resolution type in a decorative way. Bit count offers many variations in pixels shape for this. By using overlays, interesting new shapes can be created.

Stylistic variations can be made by adding layers that are slightly shifted. Due to the construction of the font, it is easy to vary the shape of the pixels within the drawing of the glyphs.

This example is made from 3 layers, each with its own color and pixel shape (bold, ring, light).
Other examples of Bitcount decorated titles can be found here.

Examples with coloured layers of Bitcount can be found here. Bitcount will soon be released by Typetr.