API overhaul

[behdad]

@anthrotype can you list what you needed from cu2qu that wasn't in the module already? I see you implemented a pen. Lets design the API we want for cu2qu, agree on it, and then make the change.

Cheers

[anthrotype]

The current cu2qu (or its rf module) only works with RFonts, RGlyph, RSegment, etc. objects as defined in robofab.objectsRF.

We wanted to apply the cu2qu core algorithm (i.e. the one in cu2qu.geometry module) to any environment that supports the Robofab pen protocol, be it robofab.objectsFL for use in FontLab macros, or defcon for converting UFOs to quadratic from command line scripts.

I'm going to pull a request for our Cu2QuPen soon. This currently only works on single fonts, not on interpolat-able font collections (the project we used it for only has one font!). I'm thinking of adding a drawPoints method to the GlyphCollection class, but I'm not sure that would work yet.

I also believe, like @behdad suggested in another thread, that the shared, non-environment specific stuff could be located in the cu2qu.__init__ module (which is now empty), instead of being in a separate geometry module.

I see that @jamesgk has reintroduced the max_err argument specifying the tolerance in absolute font units (https://github.com/googlei18n/cu2qu/pull/12). That's good. We actually haven't found an use for the relative max_err_em yet, as most our fonts are designed on a fixed 1000 UPM grid. I gather you introduced that because you want to be able to specify the same relative error for fonts having different UPMs. That is fine for us as far as both absolute-unit and relative-to-UPM tolerance values are accepted.

[behdad]

I see that @jamesgk has reintroduced the max_err argument specifying the tolerance in absolute font units (#12). That's good. We actually haven't found an use for the relative max_err_em yet, as most our fonts are designed on a fixed 1000 UPM grid. I gather you introduced that because you want to be able to specify the same relative error for fonts having different UPMs. That is fine for us as far as both absolute-unit and relative-to-UPM tolerance values are accepted.

Yes, I wanted the default to be UPM-independent.

[jamesgk]

@anthrotype I also noticed this version of curve_to_quadratic: https://github.com/daltonmaag/scope-one/blob/master/tools/convert.py#L125 which returns the error, I think it makes sense to have that here in place of our version. Would you mind contributing just that for now (or I can do it if you'd like)?

I think we'd like to make curve/s_to_quadratic the only public method of the main cu2qu module, and not even have a Point class (it would just take in lists, see PR #15). Then you or I could work on adding a generalized pen.