Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replace ctypes with.. something else? #15

Open
anthrotype opened this issue Feb 1, 2022 · 3 comments
Open

replace ctypes with.. something else? #15

anthrotype opened this issue Feb 1, 2022 · 3 comments

Comments

@anthrotype
Copy link
Member

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).

@simoncozens
Copy link
Contributor

Currently a single command (pip3 install gftools) will get you something that can build and hint fonts, even without homebrew. That's quite valuable.

@anthrotype
Copy link
Member Author

The easiest would be using subprocess to wrap the ttfautohint executable, like we do e.g. for cffsubr or ots-sanitize.

with stuff like #24 coming up and memories of my previous self fading away, I think we should revive this, because the current ctypes wrapper to libttfautohint has become de facto unmaintained/unmaintainable.

@simoncozens will you be ok if ttfautohint-py would simply call out to a precompiled ttfautohint executable that gets embedded inside it? The pip-install-ability would stay, and bugs like #24 would likely go away.

@simoncozens
Copy link
Contributor

The reason we use abstraction layers is so we don't need to care about the implementation - if it installs on all the platforms, I'm happy ...

anthrotype added a commit that referenced this issue Nov 13, 2024
We no longer wrap libttfautohint using ctypes, but prefer to run the ttfautohint executable as a subprocess. This is easier to maintain/update.
Fixes #15.
anthrotype added a commit that referenced this issue Nov 15, 2024
We no longer wrap libttfautohint using ctypes, but prefer to run the ttfautohint executable as a subprocess. This is easier to maintain/update.
Fixes #15.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants