pGlyph() > dereference() removes components

[alex-phil]

Vassil, please take a look at these lines of code that are part of the dereference() function:

https://github.com/kateliev/TypeRig/blob/85cf3dc59aa5ed7ec42cbd5501f7bbb332a68bae/Lib/typerig/proxy/fl/objects/glyph.py#L330-L335

To my understanding, dereferencing an element reference is the same as what Element > Element Reference > Unlink Reference does. If that is correct, your function does too much. It not only unlinks element references, but also removes components. Which is clear from your code:

1. You collect all element references of the specified glyph layer in a list ('only_shapes').
2. You create a clone (unlinked equivalent) of each of these references and collect these clones in a list ('clones').
3. You remove not only element references, but also components (and groups) from the glyph layer and only add the clones back in.

This way, components (and groups) are removed from the specified glyph layer. Therefore, I think you should replace

for clone in clones: wLayer.addShape(clone)

by the following:

for item in components + clones:
  wLayer.addShape(item)

This way, components are also added back in. Would that make sense?

[alex-phil]

Though I have to confess that the intended object relations in FontLab’s Python API are not entirely clear to me. Which is partly because the terminology in FontLab itself has changed since version VI. Would the following be a correct illustration of the current (FL8) relations between shapes, elements, components, and so on?

Shape
|
|— Element
|    |— Contour Element
|    |— Image Element
|    |— Sticker
|    |— Text Shape
|
|— Container
     |— Component
     |— Group

pGlyph().shapes() seems to give me elements and containers of the current glyph layer, pGlyph().containers() gives me components and groups.

[kateliev]

This way, components are also added back in. Would that make sense?

Yes this totally makes sense, will take a look at it soon. Have in mind that this probably was used more like "Flatten Layer" than "Unlink Reference". Will have to look at the scripts that use the feature to be 100% sure of it.

Though I have to confess that the intended object relations in FontLab’s Python API are not entirely clear to me....

Unfortunately you are getting confused here and most probably part of this is my fault.

For instance there is no such thing as "Container" in FL... this term was my invention. ... There are also no "Elements"... this is also a fiction that the FL team created for "calming down" the end user. There are also no "Components". :) Whatever you believe there is... it is all smoke and mirrors... :) The only thing that is true is the flShape and it can be all of those things that you list above.

Since that is bit confusing... to have a vaguely defined object that can be all too many things at once - i started calling "Containers" the flShape objects that contain something... but honestly every shape can contain anything... can be an element, component, group and filter and even be that all at once... just because it is not allowed in the GUI, it does not mean it can't be done in the API.

So it is a brilliant invention the flShape, that is bit hard for the hard core type designer to understand. They just wanted components... because they are used to work with components... thus FL gave them "fake" components that are actually locked elements :) And "shapes" became "elements", just because people started debating over the forum... "what is shape exactly.... in geometry, in type design, in philosophy and etc."... as this was a very unproductive conversation close to defining "what is the meaning of live?", FL decided to calm down the discussion, so we have Elements... I presume you get the idea...

So to conclude... there are only Shapes for us the people that deal with code... and flShape can be a lot of things. And yes it is bit hard/abstract to work with them. I have not explored all possible ways to utilize them, only those that i immediately needed.

[alex-phil]

I see, Vassil, thank you so much for your explanation. I haven’t worked with the elements concept in my own scripts very extensively (you can get quite far with glyphs, layers, contours, nodes), but I had already assumed that flShape would be the code equivalent of what is called “element” in the terminology of the FontLab user manual.

I think I will take this discussion to the FontLab forum and see whether we can get a slightly better illustration of the FontLab object model than the one that is still present in the manual. Thank you again.

[kateliev]

@alex-phil Fixed! Thank you!