fontinfo.plist unknown data retention

[typesupply]

This was on the old roadmap and hasn't been discussed lately. I think it is a good idea for UFO 4 and maybe UFO 3.

Over the last 13 years the UFO specification has been developed in major steps. This has been the case because when the format was started the binary font formats that the specification superset were not rapidly changing. The UFO specification could go several years without a major upgrade and still only need a few minor additions. The binary font specifications are changing rapidly now and the UFO specification development process needs to adapt to this.

The problem with updating the UFO specification rapidly is that the format has been designed to be authoring tool neutral. If a new bit of data is added to fontinfo.plist, authoring tools must be updated to handle this new data otherwise the data will be lost. In UFO 3 we developed a way to make official additions to the specification that won't result in data loss. This is done by using the various lib locations and the data directory with standard storage keys and formats. This works well for very small and very big changes, but not so well for changes that fall between. Unfortunately, these "in between" changes are the kinds that are being made to the OpenType specification--new tables, new fields, new data. This new data is too complex to store in the lib locations. So, we need to develop a way to handle this. We're going to do this by making a small tweak to the way that authoring tools interpret the data in fontinfo.plist.

The fontinfo.plist specification is going to gain a new section that addresses how an authoring tool should handle unknown key/value pairs. Previously, unknown pairs were considered illegal. Going forward, when an unknown pair is encountered the tool should preserve the pair and should write it, unchanged, back into fontinfo.plist during a subsequent save operation. This does not mean that anyone can add anything that they want to fontinfo.plist. (lib.plist must still be used for that.) The authoring tool should not attempt to validate the unknown data apart from ensuring that it conforms to standard Property List specifications.

This change will allow the specification to be updated incrementally without users encountering data loss. Major changes, such as additions to GLIF, will still require a complete version jump.