Tal Leming

@khaledhosny: > Interaction between few data and UFO is completely undefined. What happens when a UFO glyph gets renamed or removed? What happens when both UFO and fea define kerning,...

I'm not terribly familiar with the details of all this. Could you describe how this could be resolved and I'll work it into the spec?

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

I'm considering two possible structures for this. My initial idea was this: ``` glyph lib = { public.contourLibs : { identifier : {} } public.pointLibs : { identifier : {}...

> 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...

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...

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.

> 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...

> 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...

I think this is a good idea. This wasn't a problem in the single layer days, but it is now. Glyphs with the same name may have separate Unicode values...