Many advertisements have headlines in script fonts in which a given character is identical throughout the document. Real handwriting, however, has slight variations between "e" and "e" or between "n" and "n", for example. Try it yourself, especially by writing at your normal speed, not slower or more meticulously than usually.
Less frequent uses include mimicking stone-cut fonts.
But this realism of variation disappears in computer graphics. One could change text to several similar fonts, but most of us don't install several scripts that are graphically coordinated as if they're from the same hand, if such fonts even exist. Character-by-character substitution would be laborious anyway. Bitmap art programs are a kludge at most, largely impracticable.
The solution I propose is automatic font-swapping within a subset of fonts.
A user would designate several fonts as being mutually swappable by the running executable. The principal functionality could be performable mostly by the operating system at an application's call commanded by the user.
Text, either selected or during input, would be manually assigned one set of fonts, the same way a user normally selects a single font. Each character in the selection or input stream would then be automatically assigned a font from that mutually-swappable set, a font swapset.
Size and style would be unaffected, although size could be reconsidered for an enhancement, because an approximately ten-percent size variation is likely to be more realistic than pure consistency.
The sequence of auto-assignment of fonts and the first-character assignment would default to random, with saving of the document preserving assignments as with traditional fonts. Alternatively, the user could specify a sequence. In a hypothetical list of three fonts, specifying
would cause the second font to be auto-assigned to 60 percent of the characters.
All characters would be affected in a simpler implementation, but better would be to assign to whitespace and control characters whichever font the prior nonwhitespace graphical character had, with an arbitrary assignment to the first character if it's whitespace or nongraphical.
Since the same or similar glyphs are what human viewers are most sensitive to on this issue, it would be better to override the sequence when the same or a similar glyph is next encountered. That could be done by applying a clone of the sequence. Thus, for the sequence
and the string
she said he said
the assignments (ignoring whitespace) would be
123 2123 12 3231
123 1231 23 1231
The former is better because each "s" would be unique and so would each "h", each "e", each "a", each "i", and each "d".
Glyph similarity with nonidenticality would be specified by the user with a default specification offered for each alphabet or glyph set. A specification could be in a text file line with spaces as separators (e.g., in part, "LEF Il1 bh ij mn bp vw O0 RPp Ss cou GCOU"), as user-editable.
Most of the programming should be in one place in or near the OS, with apps slightly rewritten to take the advantage.
Kernel growth should be minimized. Arguably, usually only graphic designers will care. Therefore, a runtime-loadable user-loadable module or daemon should contain most of the intelligence for handling this solution. Permanent OS hooks should be written to impose the least overhead when the functionality is not needed during a boot or login session.
End-use applications should have little programming to support this facility, having just enough to take advantage of it, just as end-use apps have little programming in support of various kinds of printer features, but can use many kinds. Users may come to expect this facility in several major applications on one machine, so it would be more efficient to place the intelligence in one piece of software callable by all font-using applications or callable by the OS at any font-using application's behest. Application designers may have to expand the user interface a little. An app's UI offering a choice of fonts should also offer a choice of swappable font sets, perhaps in a font menu submenu that's dynamic.
Near where fonts are stored on disk, a directory should be dedicated to storing text files designating swappable font sets. Multiple text files could support multiple font swapsets, useful as different graphic designers have different artistic judgments about which fonts should be in a given set, which nonidentical glyphs are similar, and how much size variation should be tolerated.
The file should be a text file. From a hash to an end-of-line would be a comment. Lines would be counted, each line implicitly numbered except for comment-only lines. The following variables should be supported, with one variable per line:
On either side of the equals sign, inline whitespace should be ignored.
The values of the above vars would be as follows:
* "version" would be the version of support for this file, to support future expansion, with backwards compatibility supported. Edits to the file would not require editing the version value. If a user wants versioning of the user's edits to the file, a comment will do.
* "menuitem" could be read by an application and potentially assigned to naming a menu item or any comparable functionality. Ordinarily, the filename would be the same, but it needn't be, especially useful if a user wants to include in the menu item a character that can't be in a filename, such as a slash, or include in the filename a character that can't be in the menu item, such as an ampersand. This risks having two menu items that are erroneously identical, but an application optionally could present an error message to the user when starting the app and trying to populate a dynamic menu, and the user could then edit the menuitem value in one file to uniqueness or both files would be ignored for the menu.
* "menuitemaltcmd" could be read by an application and potentially assigned to the first matching string in the menuitem value, so that a user could access the menu item by keyboarding it with the alt key, as is typical for many menus. The default value would be none and a failure to match would be treated like finding no match.
* "menuitemctlcmd" could be read by an application and potentially assigned to the first matching string in the menuitem value, so that a user could access the menu item by keyboarding it with the control key, as is typical for many menus. The default value would be none and a failure to match would be treated like finding no match.
* "sequence" would default to random unless a value of random or a space-, tab-, or comma-separated one-line list of numbers is specified. The numbers, which would not need zero-padding, would correspond to font variables in order of appearance in the text file.
* "font" would name one font, optionally with a full or partial path. If no path is supplied, the default would be the path recognized for fonts by the OS. Multiple font variables would normally be present. If no font was installed for a given font variable, that variable would be ignored. If no font was installed for any font variable, the font set would appear in the font menu only as unavailable (thus dimmed).
After fonts were thus assigned, the text file would no longer be needed for the document's fonts.
Any fonts would be technologically compatible, but, to get full value, this would encourage developing sets of closely similar fonts that plausibly could represent one hand. Not many sets would be needed for designers to apply the system to graphic design. For backward compatibility, each of the new (latter) fonts would work as single fonts do now.
This facility may require that printers have more memory, because a page having many fonts can cause some printers to choke. But this general swapfont feature would be effective even with only two to four fonts representing handwriting, and many printers handle that already.
If the number of fonts (each of which must be fully loaded into a printer's memory) is a concern, I propose the multifont (or another name if this is already taken). In it, each character would be available in several glyphs. Those appearing more often in running natural language (e.g., in English, the "e", or the letters in the phrase "a sin to err", which appear more than others) could be rendered with more glyphs in a single multifont. Lower-case letters would need more glyphs than do capitals, although capitals would need more than one glyph per character for all-capital headlines. Such a multifont should work like ordinary fonts for backwards compatibility, by drawing only one glyph per character except where used as a multifont. Thus, the multifont-aware OS or program would recognize an ordinary font as really a multifont and unleash the multfont's power. Various multifonts could be designed, but only one need be installed for graphic designers to start using the technology.
To give graphic designers even more specific control, each glyph for a character would have a unique identifier, so the designer could pick the glyph desired. The default operation, however, would be for the designer to pick a multifont and let the OS or program assign glyphs just as it would from a font swapset.