Add glyph equations to built glyphs

[colinmford]

Hi @typemytype,

I have been thinking for some time it might be nice to have the equation to build a glyph constructed glyph saved in the glyph's lib, like so:

# Glyph Construction
Tcommaaccent = T + commaaccent @ bottom | 021A, 0162

<!-- T_commaaccent.glif -->
<lib>
  <dict>
    <key>com.typemytype.glyphConstruction.equation</key>
    <string>Tcommaaccent = T + commaaccent @ bottom | 021A, 0162</string>
  </dict>
</lib>

A few examples of what this would allow other scripts to potentially do:

1. Know if a glyph is a glyph constructed glyph or not, in case they either wanted not target or target constructed glyphs
2. Allow piecemeal re-construction, for example using an event to trigger a re-construction of just a few glyphs if a base glyph's sidebearings are changed without having to go back into the extension (even if the glyph was decomposed with *)
3. A way to customize "autoUnicodes()" in a way, since the equation is explicit in what the user wants the unicode to be

... And many more! (maybe)

The only hitch I can see is user-defined variables... I can see it working maybe 2 ways? Of course the Glyph Construction constants like descender, xHeight etc won't be touched, but we could expand the variables to put in the equation, or store the variable in the font lib.

$bottom = -4
Tcommaaccent = T + commaaccent @ $bottom | 021A, 0162

becomes

<!-- T_commaaccent.glif -->
<lib>
  <dict>
    <key>com.typemytype.glyphConstruction.equation</key>
    <string>Tcommaaccent = T + commaaccent @ -4 | 021A, 0162</string>
  </dict>
</lib>

or

<!-- fontinfo.plist -->
<lib>
  <dict>
    <key>com.typemytype.glyphConstruction.variables</key>
    <dict>
        <key>$bottom</key>
        <integer>-4</integer>
    </dict>
  </dict>
</lib>

...

<!-- T_commaaccent.glif -->
<lib>
  <dict>
    <key>com.typemytype.glyphConstruction.equation</key>
    <string>Tcommaaccent = T + commaaccent @ $bottom | 021A, 0162</string>
  </dict>
</lib>

If you like this idea, I could make a PR.

Thanks!

[typemytype]

to keep a reference in the glyph lib is a good plan!

one issue I see is that this lib key is not something to keep in sync, its is just a reference where the components originally came from. If a designer adjust components manually, the construction will be out of sync.

I like the second option to keep the variable in the font.lib

In the extension this could be an optional flag: Store construction in lib.

[colinmford]

Hm, good points, the "invalidating" of glyph construction glyphs that are then edited afterwards is giving me pause. I'm gonna give this more thought.

[typemytype]

duplicated data on different levels of abstraction is a pain...

however to start over from stored glyph constructions is a deliberate decision, which can be shown in a warning dialog before appling

[ryanbugden]

I’ve had a similar idea in the back of my mind for a while, and I think it would be super useful for tooling. The lib keys are just things for tools to read. I was actually wondering if the base glyph should store all dependent equations. This would be useful for a separate tool to do the following:

1. See if the glyph is being changed.
2. If the glyph being changed has any dependent equations...
3. Reconstruct those dependent glyphs.