ttyp0 — a multiscript monospaced screen font family

I’ve been working on a family of multiscript monospaced bitmap screen fonts, and I’d appreciate your comments.

Some remarks in advance:

As a monospaced bitmap font family, ttyp0 is obviously a bit of a dinosaur. I started to work on the ASCII part of the 8x16 size something like twenty years ago, because I was dissatisfied with the ugly fonts offered by X Windows; later more sizes, styles and characters were added (with very long breaks in between). The fonts are primarily intended for those old-fashioned computer users who still do most of their work using old-fashioned terminal emulator programs (like me): for programmers, system administrators, and Unix power users. It’s a workhorse — it’s supposed to “look perfectly normal”, or at least, as normal as possible given the constraints of multiscript monospaced bitmap fonts. It’s not supposed to be fancy, or cool, or to attract any attention to itself.

ttyp0 comes in five sizes (6x12, 7x14, 8x16, 9x18, 11x22). All of them have a regular and a bold version; for 8x16 and 9x18, there is also an italic. (Italic doesn’t really fit for the other sizes.) The italic fonts do contain italic parentheses, brackets, and braces, since these are also used in text, but mathematical operators, dingbats, line graphics, etc. are copied from the corresponding upright fonts. (Mathematical typesetting uses italic exclusively for Latin and Greek letters). For Hebrew, italics are replaced by semi-bold.

The regular styles (up to 9x18) are sans-serifs with constant stroke width, with the obvious exception of some very narrow letters, such as I, J, i, j, where serifs are unavoidable in a monowidth font.

The bold styles and the 11x22 regular have varying stroke width, and they are hybrid serifs (there are serifs on the horizontal strokes, but usually none on the vertical strokes). This is unorthodox, but a consequence of the low resolution bitmap: A constant stroke width of 2px would be much too dark for an 8x16 or 9x18 font, so alternating between 1px strokes and 2px strokes is the only choice. But then the contrast between thin and thick strokes is so large that serifs on the thin (horizontal) lines become necessary for compensation. On the other hand, for most letters, there is not enough horizontal space to put decently looking serifs on the verticals. The form of the serifs (slab or wedge) is uniform within one size/style, but varies between different font sizes in order to create the right text color. For Hebrew, both horizontal and vertical lines are boldened — if only the horizontal lines were boldened, they would appear too light compared to the other scripts.

ttyp0 uses a relatively large x-height. For Latin and Cyrillic, this should improve legibility; I hope that it’s still acceptable for Greek. For Armenian and Georgian, the x-height is reduced a bit; it is still larger than it should be in a monoscript font, but in a multiscript font, reducing it even more would be problematic.

The Thai font is somewhat experimental — a 6x12 matrix is not really sufficient for Thai, and even the 9x18 and 11x22 versions would benefit from some additional vertical space. Moreover, ttyp0 is a BDF font and the BDF format does not provide means for proper positioning of floating accents, so Thai vowel signs and tone marks are implemented by naive overprinting. The results are obviously not optimal.

Dubious design decisions:

Stroke contrast:
There are some spots in the bold fonts where I deviated from the conventional distribution of thick and thin strokes. Examples include the right leg of capital U, where a 1px stroke would have been too thin for my taste, and the crossbar of capital Ð, where a 1px stroke would not have been sufficiently visible. I’ve also used thick strokes for the extenders of some lowercase Armenian letters, such as գ, դ, and ռ, in order to compensate for the fact that there was not enough space to make these strokes sufficiently long. It should make these letters more easily recognizable, but I’m not sure whether native speakers find this helpful or irritating.

Commas vs. quotes:
For low-resolution bitmaps, I prefer a slanted comma to a curled one, in particular since the curled ones tend to be either too large or too close to periods. Unfortunately, slanted quotes don’t work well in a multilingual font: With curly quotes, one uses high-66 high99 for English and low-99 high-66 for German, whereas using slanted quotes, one uses high-\\ high-// for English and low-// high-// for German. As high-66 (Unicode 201C) corresponds to high-\\ in English and to high-// in German, no slanted glyph will be satisfactory under all circumstances. As a result, I am now stuck with commas that are stylistically very different from quotes. That’s not nice, but the other choices aren’t nice either.

Poor man’s kerning:
In some font sizes and styles, letters with high arms and without low arms (e.g., F, Γ) are moved to the right (compared to, say, capital E). This is intentional.

Glyph collisions:
There are some cases where a glyph collides with the following one. Most of these cases seem to be harmless, either because only one or two pixels of a glyph touch the neighbouring one (“Th” in 6x12 bold and 8x16 bold), or because the letter combination is rare (“шш” in 7x14 regular). There is one exception, namely the sequence “mm” in 7x14 regular: the letter combination is frequent in some languages and the glyphs touch each other along the full length of the stem. Still I prefer this to a compressed or asymmetric “m”. (Unfortunately, in Armenian, the frequency of wide letters (ա, խ, պ, տ,փ) is so large that using compressed glyphs is unavoidable.)

Turned letters:
Some of the turned letters, such as “ɐ” or “ə”, differ from the non-turned versions. If the “e” of, say, 8x16 is turned, it would look very similar to an “a” (and vice versa), so some disambiguation is necessary.

Diacritic marks:
In certain font sizes and styles, the bitmap font designer has the choice between making the caron unnaturally small, making the breve unnaturally large, or displaying both in the same way. As there is usually little risk of confusion between the two (orthographies using both over the same letter are virtually non-existent), ttyp0 uses sometimes the same glyph for breve and caron. The same applies to cedilla and undercomma.

Nowadays the underline character is no longer used for underlining, but for compound identifiers in programming languages and web addresses. For these applications, an underline character on the base line work better than an underline character below the base line.

ASCII non-alphanumerics:
For the non-alphanumeric ASCII characters, ttyp0 uses mostly the “traditional Unix glyphs”: Tilde is raised, asterisk is centered, less and greater signs have a relatively large angle (which works better when these characters are used as a replacement for angular brackets, such as in HTML.) The ASCII apostrophe is asymmetric (and the ASCII grave is its mirror image): People who still use these characters (rather than “typographic quotes”), use them for many different purposes, and while a slanted glyph looks bad in some of these contexts, an anorexic upright glyph looks bad all the time. (Alternative glyphs are available as an installation time option.)

ttyp0-6x12-20120421.gif27.67 KB
ttyp0-7x14-20120421.gif35.67 KB
ttyp0-8x16-20120421.gif61.37 KB
ttyp0-9x18-20120421.gif71.17 KB
ttyp0-11x22-20120421.gif66.97 KB
hrant's picture

Wow. This is the most intelligent, cosmopolitan dinosaur in history! :-) Actually I'm not sure it's too late for something like this, since many electronic devices (think of appliances, like coffee makers) still use lo-res 1-bit displays. However the constraint of monospace (which, predictably does the most "damage") although I understand your original intent, might actually be worth abandoning. How much programming is done in non-Latin, or even non-English? Unless it's important to have non-Latin text strings in programming not cause misalignment.

Pretty much all your design compromises seem superbly pragmatic. And making the Armenian (and Georgian) x-height smaller is very refreshing, especially in this niche application. And I love seeing that classical «հ» in a bitmap font! :-) Just some of your bold forms (in many of the scripts) might need tweaking.



uwe's picture

Just some of your bold forms (in many of the scripts) might need tweaking.

Which ones in particular?

Syndicate content Syndicate content