Need a general statement that UFO is not a 1:1 to binary font

[drj11]

Refer to https://unifiedfontobject.org/versions/ufo3/glyphs/glif/#advance

It seems that there are some font formats that support a negative advance (width), for example an issue about converting a PFA with negative advance to OTF.

As it stands UFO implicitly allows negative values, because the value is a number and there are no restrictions on it.

OTF cannot have a negative advance width (also, it is restricted to being an integer). Given that, i think it is worth adding some guidance text. My opinion is that a negative advance should be allowed (there are probably good uses for it), but it should come with a warning that OTF and other font formats might not support it.

Suggestion. Add:

An advance value (width or height) may be negative, but users should be aware that OTF and many other font formats do not support negative values. Therefore negative advance values should be restricted in their application and not used in general purpose fonts.

[benkiel]

It's a given that UFO is a source format, not a binary format. It allows a bunch of things that aren't valid in font binaries (floats in glyph coordinates, identifiers, object libs, etc) that are design time needs, but not compile time.

I've been looking for a place to link to that states this very clearly, and there isn't a spot that says this globally (it is stated in some specific things). There should be something more global stating this, thank you for pointing it out! Changing the title of the issues.

[drj11]

You may well be right that there needs to be a general statement that UFO is not 1:1 to a binary font. I don't think it's a problem (either that it isn't, or that such a statement is missing).

It's obvious that UFO at some points come quite close to modelling certain binary representations and at other times is both more distant and general.

An example of closeness is the qcurve value for the type attribute of a point in a glif. Or the apparent requirement to use anchors with names beginning with caret_ to model the OTF GDEF table ligCaretList.

I don't think it's a bad thing. UFO should serve as a general format, but also one which we expect will get converted to various concrete binary font-formats (in a lot of use cases).

Therefore I think it's reasonable for UFO itself to point out interesting and/or useful cases of how the UFO data model is expected to map to certain binary font-formats (as with qcurve).