Technical description of LettError Flipper

The flipper mechanism was developed by LettError to allow switching between a number of alternate glyphs for one character, to make more interesting typography. There is no semantic difference between the alternates, the variations are entirely esthetic. Also the widths and the kerning applied to the alternates is the same, because with at the time current technology and OS support it wasn't possible.
Flipper was built in PostScript, and can be used on MacOS with PS printers. Fonts with Flipper even have a degree of ATM compatibility.

The system

Flipper is based on a number of type 1 PS fonts, each containing one character set's worth of alternatives. Then there is a control font which does all the switching and administration. This is basically a modified type 3 PS composite font which calls the appropriate char strings from the type 1 fonts. The order in which the alternatives are called is part of the design of the typeface. Perhaps all versions can be called equally, perhaps there are varying frequencies for each font. For instance FontFont Kosmik has three variations and the rule was to prevent duplicate glyphs ending up right next to each other. By cycling through the three alternates, one, two, three, one, two, etc. glyphs from the same font are always two characters apart. In practice, this distance proves to be sufficient for the eye to not immediately spot the similarities. It is also possible to make random choices between the alternates, but keep in mind that with a limited number of alternates, the chances of choosing the same font are actually quite large, and the extra effort of making a random choice from the alternates that weren't used last might not make a visual difference from cycling. But this depends on the design.

The delivery

Instead of sending one font to the printer, several fonts need to travel from the user's computer to the printer. For mac, all type 1 fonts, and the type 3 control font were concatenated in the resource fork. The first font to be present in the POST resource is the one that will be investigated by ATM for drawable outlines. ATM will locate the printerfont file by filename and then look for type 1 char strings. It doesn't usually care if the glyphs it finds belong to a different font. That means that by choosing the order in which you put the type 1 fonts in the printerfont file, you can control which font will represent the Flipper font on screen. With the current state of ATM (4.x) it is not possible to make the glyph cycling appear on screen. Perhaps such things will be possible in type 2, and perhaps OpenType as well, but for now, it's one font on screen, many fonts on paper. Earlier versions of Flipper fonts had the type 3 control font in the datafork and the alternates in resource. This was useful because during development of the Flipper code the font can be opened as a text document. But Apple stopped OS support for fonts contained in dataforks (without telling anybody) and that was that. Now it's all in the resource fork. Choosing the type 3 control font as the first one in the POST resources is not recommended, ATM will think the font cannot be drawn and complain.

Note 1

ATM 4 will sometimes also complain about Flipper fonts because the PostScript name of the first font present in the POST resources does not match the name of the Flipper font itself. This is irritating not only because there are legitimate reasons for this difference, but also that ATM will label the font unsuitable. However, ATM doesn't always seem to check everything, and as long as ATM doesn't find out, it rasterises Flipper fonts fine.

Note 2

this ATM spoofing technique is also very practical when making type 3 fonts with type 1 previews. For instance FontFont Beowolf in which all letterforms are broken up randomly in the printer. This font is entirely in type 3 PostScript, but the printerfont file contains a type 1 font as well, and this is the one that ATM looks at. In the printer the type 3 font is used to draw the letters. Automatic downloading causes the preview font to end up in printer memory as well, but compared to the performance impact a genuine RandomFont makes, it is unnoticeable.

After automatic or manual downloading all fonts end up in printer memory. The PostScript description of the printing page then asks for a particular named font, which happens to belong to the type 3 control font. The control font checks if the requested glyph isn't some special character, then it looks up which version it is supposed to take (if the typeface is set up to use alternate-cycling). This is an index to a list of font names. Then it checks if the current character is indeed available in the selected alternate font. This is an optimization to reduce font size. For economical reasons not all alternatives need to be available for all characters. For instance a typeface with three alternates: the very infrequently used characters can have one version, all accented characters 2 alternatives. Upper and lowercase, numbers and most fun characters have 3 versions. Most users won't notice. When the font and the character are chosen, the alternate font is called as a normal composite font.

Automatic delivery on PC systems is a bit more sketchy. It should be possible to concatenate all PostScript binaries in one large .PFB, but there wasn't enough data available on font downloading mechanisms on the various PC flavors to make Flipper into sturdy PC product. But perhaps Adobe engineers have a clearer overview of this. Manual downloading of the fonts has always worked (on mac and PC), but it is a effort that most users will not gladly take. Flipper has worked on mac for more than 5 years.

Performance

The control font cannot be cached in the printer. Each letter on the page is taken care of the the Flipper code in the type 3 font and this takes some time. The alternates of course are all type 1 and are cached and ready. It is our experience that users are willing to wait longer for their pages as long as they are aware of why they're waiting, and also if there is an alternative path by using perhaps one of the alternates in a separate non-Flipper version of the font. In the latter situation during the design phase of a document the non-Flipper version can be used, and during final production the Flipper version can be inserted. Nothing of this is automatic though and requires a certain level of sophistication in users.
Providing users with plain vanilla type 1 versions (with different names and PostScript ID numbers) of the Flipper alternates is also recommended. For instance, when users want to build logotypes with specific glyph versions, this should be possible without too much hassle. Also converting text to outlines should be possible. When a Flipper font is converted to outlines in for instance Adobe Illustrator, the outlines will be from the preview font only.
Non-flippering alternates can also be used to access characters which have been takes out of the Flipper version to save room.

Special behavior

A user requested a way of synchronizing the Flippering characters. For instance in the case of shadowed text generated by the layout application, the user wanted a glyph and its shadow to have the same shape. This was solved by inventing a special character (option-j on mac, or delta). This character has no width, but it has an outline to indicate it is there. When the Flipper code encounters this character, it resets it's version counter, but it does not call any glyph. The synchronization character will then not print. Synchronizing also works in color separations.
It is feasible to invent other special characters will similar functions to control particular aspects of the behavior of the font. Of course control over features is best done with a real UI in context of the document editor,

Copyrights and notices

Flipper is developed by and intellectual property of LettError, consisting of Erik van Blokland (erik@letterror.com) and Just van Rossum (just@letterror.com) FF Kosmik and FF Beowolf are registered trademarks of FontShop International GmbH.