Multiglyph Font Proposal
» Email someone you know about this article.
The Problem
Script fonts should be more realistic. You write the same letter in different ways every time. (Try it. Write a paragraph with a pen at your normal speed. Don’t study the output until you’re done scribbling plenty of sample text.) A script font should also vary the same letter. Then, your message would look more hand-written. The same is true of other hand-made fonts, like for stone carvings.
Subtlety is often missed, but often it’s not, because the effect is subconscious, yet just as real. That’s why you proofread carefully against mistakes. Documents that can hardly hold a reader even if perfect, like an advertisement, need closer proofreading. It’s not that some people see a misspelling and email you about your end-of-the-world sloppiness. It’s that many people vaguely sense there’s something wrong and don’t go to the trouble of putting their finger on it. They just do the faster thing of walking away from your message. You accomplish almost nothing. I look at a direct mail piece that has a mass of large handwriting addressing me by name (how clever!) and I notice that every “e” is precisely the same, proving it’s merely by a machine. I’m an outlier, but mainly in articulating the observations. Most people are more casual about it on the way to the trash can.
Legibility would still be needed. But a letter “o” could be legible even if slightly wider or narrower. Dozens of slight variations of one character could be compatible with easy readability.
No such multiglyph font exists now, to my knowledge. You could use an art program (vector or bitmap), load the text in, and manipulate the image of the text, but that likely makes subsequent editing harder. There were fonts that let users vary the weight (Multiple Master fonts for Macintosh computers), but weight is not the only quality we want to vary (I forgot the other quality that could be varied, maybe obliqueness, but those are all there were). You could mix ordinary fonts that happen to be similar, but trying to load multiple fonts for a short headline could choke your printer’s or computer’s memory. You may need only a few letters, but using one character from a font usually requires loading the entire font, so if you need just a few letters from a dozen fonts your computer needs to load a dozen entire fonts into the memory. Even if you already installed hundreds of fonts, installing and loading are separate processes. Installing puts them on your hard drive or other storage, while loading puts them into the smaller RAM (that’s the memory you’re most likely to notice when you don’t have enough). If you’ve tried to print complete fonts for all of your fonts into one paper catalogue, you may have had difficulty getting all the pages out in a reasonable time. Often, that’s why.
This applies to all printable characters, not just the 26 letters. Look at real handwriting; even dots and commas vary. So do accents, numbers, and slashes. The same key cap or Unicode codepoint could support several glyphs.
A Solution
So, it would be better when using your computer if you could vary within a single hand-based font without needing lots of fonts, or tons of memory. This will demand special font technology, likely special software support. The kernel may even need a new capability.
Support would likely include storing, in a document, information about how the font is to be applied. That could be handled by a word processor, a page layout (desktop publishing) program, or vector art software. Thus, some applications would need to have a new capability. Without it, a default setting would be presumed, so the text would print but without the new features a multiglyph font would have. You could use the font in a database manager or a text editor, or an old version of a word processor, but you probably wouldn’t care about glyph choice there, so those programs wouldn’t need to support it. As long as we don’t get a page of missing-character symbols, a default would be fine for some applications.
Three or more subfonts would each be complete, but slightly different for every character. Because a few characters get used much more often, additional but incomplete subfonts would be included. The most common letters are in the phrase “a sin to err” (not in that order and it’s not a sin); there’d be more of those. Fewer of “j” or “q” would be fine, as long as there are at least three. Three, I think, is the minimum to reduce the likelihood of users’ discovering that characters have identical glyphs. It might even be worth designing the font to have several times more of every character, say, eight or twenty glyphs per character plus more of “a sin to err”, to support longer text blocks, for certain markets.
Glyph selection could be in the background while text is being inputted as text, not while pasting with font information. Input could be from a keyboard or by pasting plain text. A glyph could also be selectable or changeable after text is already input.
Repetition of a character would automatically cause selection of a new glyph, probably in rotation through a list or randomly. Possibly, selection would be determined or influenced by what character or glyph is adjacent on either side, including whitespace. A user could opt for a particular glyph, and should be permitted to view each glyph (magnified) and select one. Either way, once selected, which glyph is to be rendered should be stored in the document for consistent rendering over time.
Connections between adjacent lower-case characters occur at different heights in physical handwriting but at the same height in fonts. This system could (fortunately) weaken that tendency in the font, although doing so could demand more glyphs from which to choose. Likewise, a glyph appearing at the beginning or end of a word could accommodate whether a connecting stroke should appear at all.
The character width for one Unicode codepoint needs to be consistent for all glyphs for it, so that line breaks, word breaks, and page layouts would not vary between subfonts and would not have to be re-previewed (previewing once would be enough). Numeral character widths should be equal for all digits, as they are for most of the non-fancy fonts.
Glyphs rarely extend beyond character widths, but they may with titling capitals. I don’t know if they extend for any other use. I suppose a decision would have to be made about extensions occurring only below the baseline, only above the x-height, or otherwise and whether that’s acceptable in this system. It probably would be desirable sometimes, but might require additional glyphs, some without extensions.
Ascenders and descenders would have to be designed within maxima, so document designers who don’t want lines to overlap vertically could be assured of that.
The x-height could vary but would still satisfy a minimum for accessibility (that’s a feature of Garamond, Deja Vu, and perhaps a few other traditional fonts).
Text-to-speech (TTS) software should speak all glyphs for one character identically. Variance would be possible but of little value, given the usual speeds of aural rendering.
A technological approach to letting nonsupportive applications render this kind of font without the feature might be to create two paired fonts: one that would behave like an ordinary font and the other that would support multiglyph choice. Thus, a nonsupportive app, or a supportive app on a nonsupportive kernel or operating system, would call only the basic font, which would contain only one glyph for each Unicode codepoint supported, while supportive apps on supportive kernels or OSes would know to call the companion font file with the additional glyphs for each Unicode codepoint. It would know because it would read a certain unencrypted text file in a standardized location, available to all new curious apps, and that file would name all of the paired fonts: basic plus companion font file for each font supporting the feature. Installing a new font of this kind would include writing to that file. A nonsupportive app would not know of the companion font file and so would not call it. Granted, hackers can do just about anything, but we’re not talking about whether you can cause Neptune to crash into Saturn tomorrow without touching a ring, and experimenting with the companion font file in an old app would be left to hackers gulping energy drinks.
Whether an app has to be modified in its core or could be supplemented with something like an add-on or plug-in to achieve the same result is something I don’t know, and I assume that would vary by application. The same is true for the kernel or other software that always runs waiting for requests, like a Linux daemon or a Windows service.
It may make more business sense, even for nonprofit projects which can use financial surpluses, for an app to support multiglyph selection without making the feature support available to other apps. But it may eventually be spun off or perhaps initially developed as separate from any document-creating app, to be called by a document-creating app as needed.
Both the basic font and the companion font would be downloaded to a printer or other outputter like any other font. Therefore, font files should be small. So, when logic can be in either the companion font or stay in the computer, it should stay in the computer. For example, the logic identifying which glyph is to represent a character at a point in the output likely belongs with the companion font file (including the companion font file recognizing that a glyph is described in the basic font) but the logic determining how to select a glyph for that character at that point in the planned output likely can stay in the computer.
For a font with a large number of subfonts, that is, with a large number of glyphs for a character, the companion font file might be too large to fit into most printers. Thus, it might help to have several companion font files, each to hold as little as one subfont, so that a user (a publication designer) could decide how many glyphs to choose among and thereby to limit how many companion font files would need to be downloaded for a document. To that end, ways to identify which companion files are available for one basic font and which companion files are needed for a print job are needed.
Most documents would not use this. Users would likely be designers of artistic websites and high-end designers of advertising who have very demanding criteria. Artists might also use this. Multiglyph fonts would be complicated to invent but, when available, a graphic advance.
