UFO implementation checklist

[madig]

What's missing until Norad is basically feature complete:

• De/serialization of a glyph's <lib> element. The difficulty is making plist reading from and writing to an existing XML stream up until a certain point and the returning control.
• Reading and writing a layer's layerinfo.plist. Layers have a lib, too.
• Upgrading of UFO v1 and v2 formats on load according to specification recommendations. I don't think we need to support downgrading.
  • Upgrade fontinfo (and feature) data from v1 and v2.
  • Upgrade GLIF v1, which handled anchors by informal convention (emulate what ufoLib does).
• Support the data folder. It should lazily load any referenced data, as it could be megabytes of binary gunk. This probably implies a split between saving in-place (where you only write data objects that are loaded into memory and could therefore be changed) and saving into a fresh location/overwriting (where you load and then write out everything).
• Support the images folder: http://unifiedfontobject.org/versions/ufo3/images/
• Verify we have all validators from ufoLib on board. Todo:
  • identifiers! All identifiers within a glyph and separately within fontinfo's guideline list must be unique.
    • glyph identifiers.
    • fontinfo identifiers
  • guideline validators, others?
  • Point data combination validation?
  • Glif reader validation (do we cover what e.g. ufoLib's _validateAndMassagePointStructures does?)
• Track new additions to the spec
  • public objects and automatic pruning
  • Enforce use of name Strings without control characters: https://unifiedfontobject.org/versions/ufo3/conventions/#controls (Stricter names for things #191)
• More complete user name to filename conversion (Extend crate::glyph::default_file_name_for_glyph_name to reference algorithm #85)

Very nice to have:

• When serializing property lists like fontinfo and kerning, make an effort to write out integers when we have integers instead of <real> elements everywhere. The values are the same, but other tools make the same effort, and we want to keep down on diff noise.
• Better error types/API so that e.g. loading a faulty UFO produces a legible error message? Need to check all possible errors.
  • More detailed fontinfo errors
  • If missing e.g. a glif file listed in contents.plist, note the name, not just the OsError.

Deferred to later:

• UFOZ support #262
• GLIF load/save: Filter duplicate codepoints #263
• Glyph serialization: Error out if any floats are infinite, subnormal, or NaN #198
• Norad output is ideally indistinguishable from ufonormalizer output.
  • Float serialization: option to limit precision #189
  • Plist serialization: option to indent first dict element, expand empty elements #179

Other things to consider:

• The UFO roadmap wants to drop the name attribute from the glyph structure, since the name is held by the layer already. Norad should probably avoid having an API that exposes the name of a Glyph object and only ever reference it through a layer to ensure a smooth transition, should v4 ever come. Side note: I think urges to make it possible to make several names point to the same glyph object should be avoided, unless Rust makes that hard anyway. There might be weird corner cases lurking in e.g. equality testing.
• The UFO roadmap furthermore mentions a charactermapping.plist, which should contain a mapping of Unicode code point to glyph name. The side-effect is that there is a canonical source of truth; right now, the same glyph names can have different Unicode values in different layers. Since a central mapping register is the only way of handling this that makes sense to me, Norad should probably implicitly do it anyway. The v3 spec explicitly allows libs to do it: http://unifiedfontobject.org/versions/ufo3/#character-mapping. When reading, the mapping should be filled with values found in the default layer first, and with other layers on a first-come-first-map basis.
• Component circular reference checking? Component handling: add API for checked insertion and removal? #219
• The above things may change, may need more thinking and probably shouldn't hold up a v1.