You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm more and more tempted to do away with the ctypes bindings altogether.. We have issues with pypy3 (#11) and now also with M1 arm64 macs (#14).
The easiest would be using subprocess to wrap the ttfautohint executable, like we do e.g. for cffsubr or ots-sanitize.
Other options include using cffi or cython to wrap the libttfautohint library, but these probably involve more work.
Keeping this up to date with upstream ttfautohint also means that every time the upstream CLI interface changes, we have to update its python equivalent. I wonder if this is actually worth the hassle.
The way I see this ttfautohint-py project is as a handy way for fontmake to depend on a pip-installable ttfautohint, I don't actually care much whether this is done using a shared library dynamically loaded via ctypes or as a subprocess. Even after googlefonts/fontmake#562, fontmake is still calling ttfautohint-py as an external command (as python -m ttfautohint) instead of importing it as a python module.
Maybe we can even deprecate/archive this altogether and tell people to go and brew install ttfautohint (well, at least that works on Mac and maybe Linux).
The text was updated successfully, but these errors were encountered:
I'm more and more tempted to do away with the ctypes bindings altogether.. We have issues with pypy3 (#11) and now also with M1 arm64 macs (#14).
The easiest would be using subprocess to wrap the ttfautohint executable, like we do e.g. for cffsubr or ots-sanitize.
Other options include using cffi or cython to wrap the libttfautohint library, but these probably involve more work.
Keeping this up to date with upstream ttfautohint also means that every time the upstream CLI interface changes, we have to update its python equivalent. I wonder if this is actually worth the hassle.
The way I see this ttfautohint-py project is as a handy way for fontmake to depend on a pip-installable ttfautohint, I don't actually care much whether this is done using a shared library dynamically loaded via ctypes or as a subprocess. Even after googlefonts/fontmake#562, fontmake is still calling ttfautohint-py as an external command (as
python -m ttfautohint
) instead of importing it as a python module.Maybe we can even deprecate/archive this altogether and tell people to go and
brew install ttfautohint
(well, at least that works on Mac and maybe Linux).The text was updated successfully, but these errors were encountered: