designSpaceDocument
designSpaceDocument copied to clipboard
LettError
instance should have a 'lib' to store arbitrary data
When glyphsLib converts a multiple-master glyphs file into a set of UFOs + a designspace file, we lack the ability to store Glyphs.app specific data such as instance custom parameters in the designspace. GlyphsLib currently resorts to passing this residual Glyphs-specific instance data to the caller (fontmake) which then has to apply this on the instance UFOs returned from mutatorMath.
Because of that, generating instances using fontmake from a glyphs source in a single pass (i.e. from glyphs to TTFs), or in two stages (first from glyphs to UFOs+designspace, and then from these to TTFs), will produce different results, as that residual authoring-tool specific data gets thrown away.
Having a lib element in the instance element of a designspace could be a solution for this.
@anthrotype Maybe an example can help. Is this mostly for Filter and Prefilter?
No, it's for any instance custom parameter actually. It would work the same as the UFO lib, i.e. a piece of property list embedded in an xml structure.
I hope to find some time later this week. I think we could reuse ufoLib.plistFromETree module and ufoLib.plistlib.PlistWriter.
So this is a proposal <lib> element for instance. Do we need one for the top level as well? And would that be a way out for STAT data?
So this is a proposal
element for instance.
yes, that's what I'd need for storing instance-specific data from Glyphs.app (e.g. so-called "custom parameters") when I make a designspace document in glyphsLib, as I convert a *.glyphs source into a set of UFOs + designspace file.
Do we need one for the top level as well?
I don't immediately need one, but it won't hurt having one I guess.
And would that be a way out for STAT data?
Hm, I don't know. I usually view the lib stuff as custom, optional, private, editor-specific data, whereas STAT is supposedly required for variable fonts output.
I could (later maybe), but basically i’d like a place where I could dump any extra data that doesn’t fit and that a property list can store
And by the way, this is not just useful to support the two-step build (first build the UFOs and designspace from glyphs file then build OTFs from the former, getting the same result as building in one go), but also for round-tripping and going back from designspace to Glyphs file
Right, so I thought if there are things in there that have proper names and functions it might be useful to call those out.
I don't know yet which custom parameters won't fit in the existing fields (I'm just starting to use designspace documents), but I will discover them soon and report them here.
