Store information about supports

[LettError]

It would be useful to store some additional information about sources that are intended as supports in a designspace. The geometry these sources contribute to the system is pretty straightforward. Font compilers support them. But thinking about the way these glyphs are designed, reviewed, updated, there are some possibilities.

The Skateboard tool for RoboFont had some functionality for this. I'm not sure it was used a lot, but adding supports to designspaces is normal practice, so it merits some attention.

Definitions

• a support offers glyph geometry at a particular location
• a support is not a complete glyphset, it has no kerning, no font info.
• depending on the compiler it may be necessary to include components, space, .notdef
• the support has no structural, load bearing significance for the designspace: you should be able to remove it and the designspace continues to function
• changes to outlines are relatively easy
• changes to the position of components requires these components to also be in the support UFO and that could mean a group of glyphs, with all their component dependencies need to be added.

Making a new UFO, adding it to the designspace and sticking some outlines in it is quite easy. But in practice these outlines are quite isolated and fragile. They depend on the state of the whole designspace at that time. Maybe you only want to correct the weight of one stroke, the whole glyph needs to be there and that is produced by the designspace. Should the geometry of that glyph change somewhere else in the designspace, at a later date, maybe by another designer, those changes will no longer show up at the support location, as that still reflects the old state. It is easy for the points to wander off.

Proposal

It is possible to remedy this to some extent. Suppose you find it necessary to add a glyph to a Support source. The Support source is already there, it is referenced in the designspace, the UFO exists. Suppose you do this through a script: it would ask the designspace for an instance for the support location, and place that in the foreground layer. You then also copy the same glyph in another layer called reference. Initially the foreground and reference layers will be the same. But when you make the edits you need to the foreground, it will show the differences.
The reference layer can also be compared to what the designspace will generate now had the support not been there. Support for this has been added to UFOOperator.
Theoretically, the changes in the foreground of the support glyph can be isolated by subtracting the reference layer. Then add a fresh instance for the support location. This applies the original changes to the new state.

newForeground = (currentForeground - reference) + newInstance

Then copy newInstance to the reference layer, and newForeground to the foreground layer.

This depends on a lot of assumptions! This update should not be applied automatically. Big changes to the design of the other sources would invalidate the recorded changes in the support. But this is obvious to the designer. So what kinds of changes would this be useful for?

• edits late in the design process
• changes in glyph width, margins
• changes in component position
• changes in number, names, position of anchors
• changes in alignment zones (though the fontcompiler is unlikey to use this data, it will be visible in the glyph editor)
• changes in glyph data, for instance to remedy kinking

Support Tool

Tool could identify these changes, alert the designer, offer actions to remedy or update. Given a working designspace, what tasks could be written?

Make a new Support:

• For a working designspace, find the right location for a support
• Build the support ufo, save, add it to the designspace at the location
• Add information about this support source to the designspace lib.
• populate the support.info with relevant values for the location. Ascender, descender, xheight, alignment zones, italicAngle, RFItalicOffset.
• create the reference layer
• an empty vessel, with no glyphs.

Adding a glyph to the support.

• triggered by a contextual menu in a glyph, or a something that responds to a selected glyph in a font collection window. Either way it has to say "Add a support for glyph 'a' in Support B". This UI should be able to guess which source is the support.
• make a new glyph. make the layers.
• find out if this glyph has component dependencies, make a list of everything we'd need
• make all these glyphs
• for each glyph, fill foreground and reference layers with the instances provided by the designspace.

Maintenance, checking, updating

• tool is aware that a particular glyph is part of a support
• tool can draw the instance without the support and highlight the differences with the reference layer
• tool can check shifts in dependencies, in case of components
• select a point in a support glyph and say "update" and it would pop to the interpolation.
• tool can make an overview of all the changes / glyphs in the support. A pdf from drawbot

Effort

All of this is possible without the need for dedicated tools. The question if that if it is easier to make and maintain these glyphs, perhaps the design decisions would be better if they're based on better information.
However, the thing I learned from the support-support in Skateboard was that adding them changes the designspace in subtle and sometimes unintuitive ways. The influence of the other sources can shift and that means that by adding a support in one place might be detrimental for the appearance of the glyphs in another place. There is a risk of then adding another support to fix the problems caused by the first. Messy!