`needsExtraMainOutlineDrawingForActiveLayer` does not yet hide corner/cap components

[Mark2Mark]

When needsExtraMainOutlineDrawingForActiveLayer returns NO, don’t draw:

• [ ] The thick blue component stroke
• [ ] "Color Layer" content (e.g. Stroke, Fill, Shadow, Gradient, etc)

[Mark2Mark]

This still happens, and does not make sense IMO. Hiding the layer drawing should hide all things drawn on the layer.

Here an example with the hiding setting active in Variable Font Preview. You can see how everything is nicely hidden, making way for the reporter’s drawings, but the corner halos still show:

https://github.com/schriftgestalt/GlyphsSDK/assets/5824595/aea00532-6488-4296-a41e-1111593513b2

[Mark2Mark]

any insights on this @schriftgestalt / @florianpircher?

[florianpircher]

The thick blue component stroke is drawn as part of the background by the tool. A reporter only draws additional background content, so that cannot suppress the blue lines.

The same goes for the color layer drawing.

Either we add a new API for a reporter to suppress the background of the tool, or maybe needsExtraMainOutlineDrawingForActiveLayer should also control the background. @schriftgestalt?

[Mark2Mark]

Thanks for explaining. Both options would be nice to have.

[florianpircher]

I think I might have a reporter use case where I don’t want the main outline and color drawing, but the blue corner paths should stay.

To future-proof this, we could offer a new API where a reporter returns an option set like

GSDrawSkipLayerMainOutline | GSDrawSkipLayerColorContent | GSDrawSkipLayerCornerHighlight

or similar.

[Mark2Mark]

Should the option set also offer anchors? I think currently they are hidden along with the outlines, if I’m not mistaken. Could imagine cases similar to your blue corners.

[florianpircher]

It may make sense to consolidate anchors and other stuff like metrics, mark cloud, etc. into the option set. NSUInteger has 64 bits, so there should be more than enough room for any current and future options.

[schriftgestalt]

That goes out of hand very quickly. So keep the options low. Also adding things later needs to be done in a way that we don’t need to update all code that uses this to add the new flags.

[florianpircher]

The idea would be to suppress specific, small things per bit in the option set. That way, a reporter can be selective about what it needs suppressed. For common groups, we can offer named constants combining multiple small things, e.g.

GSSuppressDrawingLayerContent = GSSuppressDrawingLayerMainOutline
    | GSSuppressDrawingLayerColorContent
    | GSSuppressDrawingLayerCornerHighlight
    | ...;

Adding things later would not be an issue as we would use the higher, previously unused bits for that. Existing reporters have those bits set to 0, so they would not suppress new things unless they opt into doing so with an update.

The named groups, like GSSuppressDrawingLayerContent can get changed in a Glyphs update, so if a reporter is not selective and just wants to get rid of ”all layer content drawing“ or “all metrics drawing” or similar, those reporters would use the named option groups and be automatically updated to suppress new stuff as it is introduced by Glyphs, as long as the new stuff fits into one of the existing named groups.

[schriftgestalt]

But if that extra bit means we do not hide certain things any more (if we e.g. discern between anchor and corner highlights), then all code that relies on hiding both needs an update. Or we need to provide enums with various levels of hiding so that we split a bit but provide the old enum with a new value that triggers both new bits. That is confusing.

[florianpircher]

The old bit would become legacy. Say bit 3 hides anchors and corner highlights. Reporters use bit 3. Time passes. We now want to discern between the two. Bits 0–5 are already assigned. So bit 6 becomes anchors and bit 7 becomes corner highlights. For backwards compatibility, if bit 3 is set, we assume 6 and 7 are set.