Why not Anchor Lib?

[typoman]

If a script is dealing with generating contextual mark positioning and the information was inside the anchor lib not in its name then it would be more convenient to interpret the anchor while generating the feature. Also differentiating the cursive attachment anchor and mark positioning anchor is primitive atm. Right now the method is to have a certain naming scheme for the anchors but if the information that is going to be interpreted while generating the mark positioning is larger then differentiating the anchors just by name seems inconvenient and messy. If there was an anchor lib, I suppose I could add a string 'type' key to the anchor lib and explicitly say it's a cursive attachment anchor by putting a string 'cursive' as the value of the key. Also using 'context' and then putting some other information there. Imagine if the context is large, then naming the anchor to indicate this is not the way to go. Why not adding a lib or some sort of mechanism to take care of this in the anchors?

[moyogo]

There is an issue on the topic of ligature anchor which expended to better anchors in general on the ufo-spec: unified-font-object/ufo-spec#32

[benkiel]

Currently, there isn't an anchor Lib because RoboFab didn't have it, but it's worth considering and discussing

[typesupply]

The lib would need to be stored somewhere and the UFO doesn't support that. We considered adding a <lib> element to everything long ago (specifically, I wanted point.lib), but decided that the complexity wasn't worth the functionality. But, I agree that using naming schemes is not idea. That was part of the reason we added persistent identifiers to various UFO objects. Here's what you can do:

1. Establish a storage location for anchor data in the glyph lib.
2. Get the identifier for a given anchor.
3. Use that identifier in the glyph lib to reference the anchor.

Something like this:

# storage location
libKey = "design.bahman.anchorstuff.something.etc"
if libKey not in glyph.lib:
    glyph.lib[libKey] = {}

# get the anchor's identifier
identifier = anchor.generateIdentifier()

# store the anchor's data
glyph.lib[libKey][identifier] = dict(foo=1, bar="yes", hello="world")

You can then reference that as needed.

Does that help?

[typoman]

Thank you very much for your input. What you suggested Tal is a good solution for now and it helps. But it also opens a room for unexpected things to happen. This way if the anchor gets deleted then the information still remains in the UFO:

glyph = CurrentGlyph()
anchors = []
libKey = "design.bahman.anchorstuff.something.etc"
if libKey not in glyph.lib:
    glyph.lib[libKey] = {}

for anchor in glyph.anchors:
    identifier = anchor.getIdentifier()
    glyph.lib[libKey][identifier] = dict(foo=1, bar="yes", hello="world")
    anchors.append(anchor)

for anchor in anchors:
    glyph.removeAnchor(anchor)

print(glyph.lib[libKey])

Also I think adding the anchor lib would be cleaner to interpret and also more explicit in terms of being pythonic.