Open ctrlcctrlv opened 3 years ago
That maybe something to consider for UFO4.
For UFO3, FontForge can use the public.objectLibs
key to store object data like the contour name.
See context here: https://github.com/unified-font-object/ufo-spec/issues/115
@benkiel I still think <contour>
should allow name="…"
for consistency sake, but respect your opinion it belongs in <lib>…</lib>
. I presume so that people can represent a contour as a simple vector/linked list type?
I'm going to open this again as a thing to possibly consider for UFO4, but here is my current thinking on this:
For this kind of thing, having a contour.lib
is much more flexible. A lib
for a contour would let an editor store multiple things about the contour that it may want to know (name, its selection state, hinting info, special editor specific transformations to apply, etc —note these examples are just that, possibilities off the top of head, not things that are currently happening). It's much more flexible, and I like having that flexibility.
contours have identifiers same like points have, to connect additional data
and like Ben proposed a lib for-everything is much more flexible
Flexibility and consistency are different (not necessarily mutually exclusive) goals.
FontForge supports naming its contours, but because the spec does not allow a name field for contours, only points, this data is dropped.
Is there a reason that contours cannot be named?