search

robotools / fontParts

The replacement for RoboFab
MIT License
133 stars 44 forks source link

Check Object documentation for Glyph(?) #743

Open knutnergaard opened 4 weeks ago

knutnergaard commented 4 weeks ago

Even though there is no open issue with regard to this, I'm assuming glyph.py should be revised with type annotations and updated docstrings, similarly to other modules in the pipeline.

If so, there is an issue with the type hinting of the pen-related methods: what should their annotated pen type actually be?

One option, which is in line with my revisions in font.py and layer.py, is to use the appropriate abstract base classes from FontTools (like AbstractPen and AbstractPointPen. This is straightforward and allows direct cross reference to their documentation, but mandates a dependency on FontTools. Another, more flexible, but complicated option is to define specific typing protocols for pen objects, which only restricts the environment objects in terms of how certain methods should be defined.

I'm not sure which of these is the best for FontParts, or how a protocol for e.g., Pen and PointPen should be defined. What say you, @benkiel, @typesupply?

benkiel commented 3 weeks ago

The dependency on fontTools AbstractPen and AbstractPointPen is ok — we already have that dependency, and fontTools is the standard now for the pen protocol

knutnergaard commented 2 weeks ago

@benkiel, does it make sense to mandate subclassing of FontMath objects on similar grounds (e.g, with regard to the BaseGlyph._toMathGlyph and BaseGlyph._fromMathGlyph methods?

Also, are the BaseObject classes and the mixin classes intended to be part of the documentation? There are a few cases where it would make sense to reference them in other classes.