To what extent, if any, should norad collaborate with MFEK/glifparser.rlib?

Nobody has claimed this yet.

Hello,

I just got done writing glifparser v1.0.

glifparser was written primarily for MFEKglif but it's also used in MFEKstroke, and in MFEKufo (unreleased) for previewing glyphs.

[It's currently in `mfek` branch](https://github.com/MFEK/glifparser.rlib/tree/mfek), awaiting @MatthewBlanchard and I to patch MFEKglif and MFEKstroke to support the changes. The biggest change is that there are no more panic's, originally, I just panicked via `.expect(...)` in a lot of cases because I knew MFEKglif was the only consumer and had a custom panic unwinder that would pretty print the message in red and make it clear what went wrong.

glifparser can do quite a few things norad cannot:

* "flatten" a glyph with components to its constituent contours, detect loops and bail out (uses `kurbo::Affine`!)
* allow arbitrary data storage along with points via generic type attached to points
* most importantly for MFEKglif project, deal with _unattached_ .glif files that aren't part of a parent UFO
* convert glif to SkPath (Skia path), piecewise contour (needs MFEK/math.rlib for this one)
* load image data if glif has a parent UFO and image exists

I was thinking, maybe `norad` can support using `glifparser` at user option, via compile-time feature. Right now what I'm doing is, using `norad` with the `UfoDataRequest` I added and just not reading glyphs with it, using it for metadata only.

I think closer collaboration is possible. Is it desirable?

Start by reviewing the issue discussion and the glifparser `mfek` branch, then compare its capabilities with norad and the existing `UfoDataRequest` usage. Clarify whether optional collaboration or integration is desired, and define the supported behavior and scope before implementation.

Written by the indexing model from the issue text.