More libs.

[typesupply]

(Copied from my comment in #93)

---

There has been some interest in adding a lib attribute at the API level in defcon and fontParts for objects that don't currently have a lib. contour.lib, component.lib, etc. Putting that on objects is no problem, but we'd need to store it in UFO and that is much more difficult. GLIF readers/writers are hardwired to the current GLIF schema and those will need to be updated to handle new elements and attributes. The structure of ufoLib.glifLib makes it pretty easy to do this, but the other readers/writers out there are out of our hands. I've been thinking that we could handle it this way until we feel comfortable making a major format change. In the GLIF <lib> element, establish some new public keys:

• public.contour.lib
• public.component.lib
• public.etc.lib

Each of these keys would have a dict as their value. The dict keys would be the object identifiers and the values would be dicts.

At the ufoLib.glifLib level or even the defcon level, when reading GLIF these parts of the lib would be popped from the dict and set as the lib of the object with the matching identifier.

---

So, for this use case, the component flags would be located here in the defcon and fontParts API:

component.lib["public.htic"]["useMyMetrics"]
component.lib["public.htic"]["round"]
component.lib["public.htic"]["overlap"]

In the UFO the data would be stored in the GLIF like this:

<lib>
  <dict>
    <key>public.component.lib</key>
    <dict>
      <key>component1</key>
      <dict>
        <key>public.htic</key>
        <dict>
          <key>useMyMetrics</key>
          <true/>
          <key>overlap</key>
          <false/>
          <key>round</key>
          <true/>
        </dict>
      </dict>
    </dict>
  </dict>

This could be implemented pretty quickly and be backwards compatible without risk of data loss.

[belluzj]

I can think of 2 other use-cases at least for this in glyphsLib, where Glyphs.app has more information about components and guidelines than what fits in standard fields of the UFO format, and for which we currently either have something in the lib in a similar way as above or where we put the extra data in the name of the guideline and then read it back from there, in a hackish way

I suppose standardizing those would be useful.

[schriftgestalt]

Having a standardised way to store that info is very welcome, the closer to the object as possible. The current system (mentioned by belluzj) is very fragile as changes to the component (reordering, changing glyph names) will break stuff.

The most important part is the key/identifier to link to the components. Names are not good as there can be more then one component with the same name.

I hope we can move that into the native object model as soon as possible.

[moyogo]

I just have a comment about the examples:

component.lib["public.htic"]["useMyMetrics"]
component.lib["public.htic"]["round"]
component.lib["public.htic"]["overlap"]

These should really use "public.truetype" because these are really TrueType flags that may be consumed by htic, fonttools or whatever.

[schriftgestalt]

I was speaking about the <key>component1</key> key to access the component.lib, not what is inside the lib.

[typesupply]

This seemed to have broad consensus during the meeting. I'll assign the task to myself and write a draft.

[typesupply]

I'm considering two possible structures for this. My initial idea was this:

glyph lib = {
    public.contourLibs : { identifier : {} }
    public.pointLibs : { identifier : {} }
    public.componentLibs : { identifier : {} }
    public.anchorLibs : { identifier : {} }
    public.guidelineLibs : { identifier : {} }
}

However, I reviewed the GLIF identifier specification and noted that identifiers must be unique within an overall glyph, not just the objects of the same type as the object that the identifier belongs to:

The identifier value must be unique within all identifiers (including identifiers for elements other than contours) in the glyph that the contour belongs to but it is not required to be unique among the identifiers assigned in other glyphs, in any layerinfo.plist or in fontinfo.plist.

Now I'm wondering if we should do something simpler than my initial idea:

glyph lib = {
    public.objectLibs : { identifier : {} }
}

@justvanrossum Do you have any thoughts? I'm leaning towards the single dict in the latter idea.

[justvanrossum]

Uh, I thought we wanted to add libs on the actual objects:

glyph.anchors[0].lib["..."]

Say,

<anchor x="100" x="200>
  <lib>
    ...
  </lib>
</anchor>

Likewise for contours and components.

[typesupply]

Uh, I thought we wanted to add libs on the actual objects:

Yes, eventually, but if we want to roll it out quickly we can't change GLIF. We can do it via a lib key now and make the change to GLIF for UFO 4.

In defcon/fontParts you'd be able to do glyph.anchors[0].lib["..."] because we can either unpack the lib and set it in the corresponding object at load or map to it the glyph lib behind the scenes.

[typesupply]

Here is a draft of the UFO 3 - GLIF documentation addition. Unless there are comments or objections, I'll submit a PR for this in a few days.

public.objectLibs

This key provides a dictionary of data containing object-level lib data for individual contours, points, components, anchors or guidelines within the glyph that this lib belongs to. The dictionary is structured with object identifiers that correspond to objects in the glyph as keys and object-level dictionaries as values. Within each of these of these object-level dictionaries, keys should follow a [reverse domain naming scheme]. The pattern "public.*", where * represents an arbitrary string of one or more characters, is reserved for use in standardized lib keys. It is recommended that the data stored as a value be as shallow as possible. If a key in this dictionary is not an identifier of any object within this glyph, the key and value may be discarded.

<key>public.objectIdentifiers</key>
<dict>
  <key>vMlVuTQd4d</key>
  <dict>
    <key>com.foundry.contourColor</key>
    <string>1,0,0,0.5</string>
  </dict>
  <key>KN3WZjorob</key>
  <dict>
    <key>com.foundry.pointColor</key>
    <string>0,1,0,0.5</string>
  </dict>
  <key>h0ablXAzTg</key>
  <dict>
    <key>com.foundry.pointColor</key>
    <string>1,0,0,0.5</string>
  </dict>
</dict>

[typesupply]

I've added the documentation for this to UFO 3. I'll leave this issue open as a reminder to write the element documentation for UFO 4.

[madig]

Question regarding https://unifiedfontobject.org/versions/ufo3/lib.plist/#publicobjectlibs: the shown example has a top-level key of com.sometool.smartGuides, shouldn't that be public.objectLibs so the the snippet reads:

<key>public.objectLibs</key>
<dict>
  <key>7pdbofkUhz</key>
  <dict>
    <key>unicodeCategory</key>
    <string>Lu</string>
  </dict>
  <key>z1bkCMlhNb</key>
  <dict>
    <key>contourCount</key>
    <array>
      <string>&gt;</string>
      <integer>0</integer>
    </array>
    <key>glyphNamePattern</key>
    <string>*.sc*</string>
  </dict>
</dict>

(aside, the example data makes little sense for guidelines -- I can send a PR to update the text?)

[typesupply]

the shown example has a top-level key of com.sometool.smartGuides, shouldn't that be public.objectLibs so the the snippet reads:

Yes.

(aside, the example data makes little sense for guidelines -- I can send a PR to update the text?)

It's actually the data from a tool I made for myself:

• 7pdbofkUhz will only be shown in uppercase glyphs.
• z1bkCMlhNb will only be shown in glyphs with ".sc" in their name and > 0 contours.

A better example is probably a good idea.

[madig]

Ok, PR coming soon (tm).

Another question: my draft implementation for ufoLib2 adds a lib attributes to Guideline, etc., which makes the validators explode. Should all the relevant fontTools.ufoLib validation structure prototypes be extended with lib=(dict, False)?

[anthrotype]

if all objects that have an identifier can now have an associated lib, then ufoLib should be changed to allow lib dict on those objects.

[typesupply]

Another question: my draft implementation for ufoLib2 adds a lib attributes to Guideline, etc., which makes the validators explode. Should all the relevant fontTools.ufoLib validation structure prototypes be extended with lib=(dict, False)?

To be honest, I haven't thought in depth about how to implement this in ufoLib/glifLib. I had some thoughts when I wrote the spec, but would need to write some code or at least pseudo-code to verify my ideas. If you need me to do that, please let me know from fontTools or wherever.

[madig]

Hm! I'll experiment. You can look at my ufoLib2 draft PR above if you want to look at something.

[madig]

We settled for a different approach where we don't need .lib on identifiable objects, so no change in ufoLib is needed from our side.