Add property factory to `BaseInfo`.

[knutnergaard]

To improve documentation and annotation of BaseInfo attributes, I would propose adding a property factory which generates the attributes at runtime.

See this module for reference. It generates properties from a list of attribute names and adds values automatically based on glyph dimension, which may be overridden by the user. Attributes are documented with a simple summary line mapped to properties in ENGRAVING_DEFAULTS_ATTRIBUTES. Proper linting support is secured with stubs of annotated attribute names inside the class body.

BaseInfo would require a bit more complex type handling, but the basic approach for the base class should be the same.

I guess fontTools.ufoLib.fontInfoAttributesVersion3ValueData could be used as the source for attribute name and type, although the container types listes are not exhaustive in specification of items. Nor does it include description fields for each attribute to be used in documentation.

Perhaps fontTools.ufoLib.fontInfoAttributesVersion3ValueData could benefit from an upgrade in this regard?

[knutnergaard]

I raised an issue on the fonttools repo a while back about upgrading fontTools.ufoLib.fontInfoAttributesVersion3ValueData to benefit FontParts, but to no reaction. If this seems beneficial, according to the above, and with regard to #812, perhaps someone here could chime in?

Otherwise, fontParts could recreate the dataset with whatever needed.

[benkiel]

I think this would be a good addition to ufoLib, will chime in

[knutnergaard]

It seems that the fonTools maintainers have little interest in prioritizing this. Perhaps it's best for FontParts to just implement its own fontInfoAttributesVersion3ValueData extension, especially since BaseInfo is one of the few items left to document before moving to v1?

[benkiel]

I'm ok with that. Agree that it's not getting much traction at fontTools.

[knutnergaard]

@benkiel To better utilize the already existing code, I decided to opt for a simpler, documentation-specific solution in #812 (See last comment).