Decouple the closure based glyph segmentation functionality from GlyphSegmentation.

[garretrieger]

• GlyphSegmentation contains common structures around representing a segmentation.
• The specific closure based implementation of glyph keyed segmentation is moved to it's own file and own util closure_glyph_segmenter/closure_glyph_keyed_segmenter_util.

[skef]

This API assumes that glyph groups will be (in effect) pre-segmented and provides no information about the priority of the segments (e.g. relative frequencies) or the relationships between segments (e.g. which set of locales each relates to). So, it preserves the qualities I've expressed concerns about elsewhere: It assumes that something else has divided up glyphs prior to calling it but what that thing has done is then expressed in terms of codepoints, washing away much of the dependency information it presumably took into account.

Maybe some other group would find a use for this but it doesn't address our needs.

What would help is modularizing encoding as a whole: "Draw a line" through ift::encoder separating out utility functions from "substantive" functions, with a corresponding ability to select among encoders in font2ift and configure them independently. Then the approaches could easily share the code for creating segments, adding conditions, and so forth.

[garretrieger]

This API assumes that glyph groups will be (in effect) pre-segmented and provides no information about the priority of the segments (e.g. relative frequencies) or the relationships between segments (e.g. which set of locales each relates to). So, it preserves the qualities I've expressed concerns about elsewhere: It assumes that something else has divided up glyphs prior to calling it but what that thing has done is then expressed in terms of codepoints, washing away much of the dependency information it presumably took into account.

The plan is to add both frequency and dependency information to the input, but on further thought since we haven't nailed down exactly what that looks like in the more general case it's probably premature to introduce an interface. I'll rework this to keep the closure based segmentation specific implementation separated out into it's own class but remove the interface for now. Down the line once it's needed we can reintroduce an interface in whatever form makes sense.

Maybe some other group would find a use for this but it doesn't address our needs.

What would help is modularizing encoding as a whole: "Draw a line" through ift::encoder separating out utility functions from "substantive" functions, with a corresponding ability to select among encoders in font2ift and configure them independently. Then the approaches could easily share the code for creating segments, adding conditions, and so forth.

The way I've got font2ift currently set up I believe matches what you're describing. Currently font2ift implements only the serialization part of the encoding process. As an input it takes an encoder config which among other things describes an already fully formed glyph segmentation. font2ift doesn't use any of functionality from closure_glyph_segmenter.*.

So at the present producing an IFT encoded font looks like this:

1. Some utility/tool is used to generate the glyph keyed and table keyed segmentation plan and outputs that in the form of an encoder config. That could be done by "util/closure_glyph_keyed_segmenter_util", "util/iftb2config", or some other completely different implementation.
2. The encoder config from step 1 is fed into font2ift which then generates the initial IFT font and all patches according to the plan in the config.

[skef]

The way I've got font2ift currently set up I believe matches what you're describing.

I don't think it was before #99 was merged but at a quick glance it's looking closer to that now. I'll look in more detail.

[skef]

OK, I understand this better now. (I first reviewed this PR relative to my understanding of the repo prior to the last big merge.)