Allow binary fonts in SourceDescriptor?

[twardoch]

@behdad @LettError I often find myself building interpolatable TTFs using "other" tools (e.g. FontLab). Or I use the UFOs but then once the interpolatable TTFs are built, I postprocess them.

I would still like to use .designSpace to describe the family relationships. fontmake also builds interpolatable TTFs first from UFOs, and my impression is that it actually only needs the .designSpace document when it already has the TTFs.

Is it or would it be principally permissible to not use UFOs in the master SourceDescriptors but TTFs or OTFs?

[LettError]

I think the format should be able to facilitate that, and informally, as it is XML you can already do that.

However, it's not just an issue of the format: there is released code that does not expect anything but ufo, that might cause some problems. One would have to parse the whole document to find out whether the tool can actually process it.

How would you approach documents with mixed sources? Some ttf, some vfb, some glyphs even, and some UFO?

[behdad]

You've seen what we do in fontmake / varLib: use a finder function to substitute ttf for UFO. So yeah, I'm also interested in a cleaner solution, but not sure what.

[twardoch]

I’d be inclined to allow for an optional attribute in the top element that would indicate the fibt format used throughout the designSpace document. I think it should be assumed that all font resources in the designSpace document refer to the same format — after all, designSpace is about connecting related fibt resources for interpolation. So just as they need to be compatible in the sense of geometry, they should be compatible in the sense of format.

Fortunately, designSpace is still relatively new as a format — it's not the native format for Superpolator, while the deployed code could perhaps be made aware of the new attribute and ignore designSpace documents that refer to incompatible font resources.

Not a great analogy, but video container formats like MOV or AVI allow for a number of video and audio streams that use different codecs. Not all software allows all codecs so some MOVs or AVIs are not playable everywhere. But this does not invalidate the usefulness of these video container formats — in fact, it's a design feature :)

Best, Adam

[twardoch]

fibt=font

[davelab6]

just as they need to be compatible in the sense of geometry, they should be compatible in the sense of format

I think this is right; its up to software reading the designSpace to do what is needed, eg, convert UFO to TTF and combine with other compatible TTFs (which may be converted from .glyphs, other UFO versions, or be binary TTFs made with FontLab/etc)