Type Network


/ News /

The making of Bitcount

The Bitcount project started in the late 1970s 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.

That’s because printing typefaces were hidden deep inside commercial typesetting machines (as photo negatives, not even as digital information), or stored as bitmaps 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 were 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 were 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 was ever 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. Simple 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 join stems, but on the top right of the n it is, because that is traditionally the darkest part of the lettershape.

The contrast makes the difference between n and h three 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,” or “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 for 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 has all but disappeared, due to the increase of screen resolution and the availability of antialiased type on screen.

On the other hand, designers may decide to use the vintage character of low-resolution type in a decorative way. Bitcount offers many variations of pixel shapes 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 using colored layers of Bitcount can be found here. Bitcount will soon be released by Typetr.