'com.github.googlei18n.ufo2ft.filters' are not converted back to Glyphs filters custom parameters

[anthrotype]

I think I knew this but had forgotten. I just stumbled on Rubik.glyphs where the GSMaster have userData containing raw "'com.github.googlei18n.ufo2ft.filters" keys:

https://github.com/googlefonts/rubik/blob/e337a5f69a9bea30e58d05bd40184d79cc099628/sources/Rubik.glyphs#L1746-L1754

since userData is passed through unchanged into the UFO lib, fontmake (ufo2ft) happily applies the filters whereas fontc doesn't know that it may have to look at the userData for ufo2ft-specific lib keys, only looks at the Glyphs native customParameters, so it will not e.g. flatten the composite glyphs when building Rubik.glyphs

I see that the FilterParamHandler class only has to_ufo but doesn't have a corresponding to_glyphs which would convert those lib elements into equivalent Glyphs filter custom parameter definitions:

glyphsLib/Lib/glyphsLib/builder/custom_params.py

Lines 941 to 949 in 52c9823

	The handler below only handles the latter, one-way case. Since ufo2ft
	filters are a UFO lib key, they are automatically stored in a master's
	userData by another code path.
	"""
	def to_glyphs(self, glyphs, ufo):
	pass
	def to_ufo(self, builder, glyphs, ufo):

We also have a write_glyphs_filter function in

glyphsLib/Lib/glyphsLib/builder/filters.py

Line 78 in 52c9823

def write_glyphs_filter(result):

which doesn't seem to be used anywhere.

I wonder if @belluzj or @madig remember why it was done this way and the ufo->glyphs path was never implemented for filters?

[schriftgestalt]

the filters are added always added to the ufo but are not needed/useful in the .glyphs file. So I don’t see a need to round trip them. They are kind of an implementation detail if ufo2ft.
So fontc needs a similar setup to add "default" filters (or implement it however fits).

Or are there manually added filters that need to be preserved?

[cmyr]

So I'm missing something, if anybody can clarify

• at some point this file was a ufo or designspace (is this true?)
• it was converted to a glyphs file, and 'flattenComponents' was written into userData
• when glyphsLib converts to a ufo, it takes these out of userData and converts them into filters, which ufo2ft knows how to handle

The part I'm confused by is who wrote them into userData in the first place? Like did they start out as com.github.googlei18n.ufo2ft.filters entries in the UFO? Were those added manually be the designer?

[anthrotype]

did they start out as com.github.googlei18n.ufo2ft.filters entries in the UFO? Were those added manually be the designer?

yes

[anthrotype]

flattenComponents is an optional ufo2ft filter, it can be enabled either by passing a CLI flag in fontmake (I believe it's --filter FlattenComponentsFilter?) or by storing that lib key in the UFO lib.plist

[madig]

I wonder if @belluzj or @madig remember why it was done this way and the ufo->glyphs path was never implemented for filters?

I don't remember :/

[schriftgestalt]

I wasn’t there when this was implemented. But I suspect that in the beginning there were only the "filters" that implement default behavior of Glyphs. And moving them to Glyphs doesn’t make much sense. And it was never formalized to support other than those filters.