I guess it's best to address each of these, individually:
>The title suggests that the patch cleans up something; it does not; it
>implements a redesign.
Well, I guess so, the reason I call it clean up is because previously there was a lot of duplicated code, magic numbers, poorly named variables... all the big names. I started it with the intention of not changing the working code, but as I got into it, it seemed that there the old code was iterating over the whole of the subset glyph list several times... A job that could have been made simpler through recursion. I didn't redesign it, because if I were to do so, I would have changed FontFileReader by removing the write method, and remapping the glyphs when the glyph data is extracted from "glyf". (see the TODO)
>Without knowing much detail about Glyf tables, I was a bit surprised about the
>method names GlyfFlags.offsetToNextComposedGlyf(int flags)...
Ok, for this you have to read the TTF spec. But, the flags represent the properties and parameters of the composed glyph and, depending on which flags are set, the number of bytes until the next glyph data.. That method returns the offset to the next composed by reading which flags are set, and which aren't. Since none of the glyph parameters are changed, we just want the offset to the next composed glyph.
> GlyfFlags.moreComposites(int flags)
This analyses the flags, checks whether the current data is the last glyph in the "glyf" data we are reading. It is simply used to control the do-while loop.
Hope that helps, the glyf table spec can be found at: http://www.microsoft.com/typography/otspec/glyf.htm
I think this change more is more consistent with the spec, since composite glyphs can be recursive, it seemed prudent to me to clean-up/redesign the code to match that.