Hack
Hack copied to clipboard
source-foundry
Transition to ttfautohint-py instruction set scripting?
@anthrotype
Cosimo - possible to provide us with some details on how the approach in the ttfautohint-py project will affect Win and macOS users relative to builds from FreeType/Harfbuzz/ttfautohint source? As I understand it, they will not need to have XCode command line tools installed on macOS and will not need MinGW/Cygwin for Win to build. Simply pull cross compiled (i.e. user does not need to compile themselves) wheels for Linux/macOS/Win from PyPI? Am I understanding this correctly?
pip install ttfautohint-py
will automatically download the right binary package for the target python platform and architecture. You don’t need any compiler, it’s all pre-compiled.
Or maybe I didn't get your question right. You'd use pip if you want to install from the wheel packages. If you mean how to build from source, then of course in that case you will need the compiler toolchain and some extra development tools (as explained in the readme).
I haven't provided a source distribution package (sdist) for ttfautohint-py yet, only binary wheels for now. The source for ttfautohint-py is its git repository.
The problem is that the code necessary to build the shared libttfautohint library hasn't been released yet, it's only available from the ttfautohint git repository.
So, for now I need to build ttfautohint from its git repo, which means the simple ./configure && make isn't enough since there are generated files that require autoconf, automake, libtool, bison, flex, etc.
For harfbuzz and freetype I could use the respective tarballs instead of cloning them as git submodules as I'm currently doing. I plan to do that as soon as ttfautohint with shared lib support is released.
Then I can make a sdist for ttfautohint-py, which will either include the source archives for harfbuzz, freetype and ttfautohint, or it will download them from their official URLs and build them from source. I haven't decided yet.
I think I will also define an environment variable (e.g. TTFAUTOHINT_PY_EXTERNAL_LIB=1) or a setup.py option so that one can only build/install a pure-python ttfautohint package without the embedded libttfautohint library. I imagine that linux distros will eventually install libttfautohint as a system library, and ttfautohint-py should be able to load that if the embedded one is not present.
I think you addressed it in the first response. Trying to sort out if this helps a population of users here. The elimination of the need to compile ttfautohint and dependencies from source definitely, definitely does! (and will dramatically speed up builds including CI testing)
@anthrotype can you confirm that libttfautohint is current with the ttfautohint v1.7 changes? The executable uses this library and this is where changes to the executable application occur?
Also, will you be building new versions of ttfautohint-py to stay current with new changes to ttfautohint as they are released?
yes, it has the latest ttfautohint (from git), harfbuzz and freetype (latest stable releases): https://github.com/fonttools/ttfautohint-py/releases/tag/v0.1.0
sure, I plan to keep it up to date
Those will be important issues for us here. We need the latest release based upon features there and may need current releases for new features in the future. Wanted to confirm as we consider a transition to a new approach to the instruction sets. Thanks for your help and for developing this Cosimo. This project will definitely be helpful to us.
it's very simple to update the embedded libttfautohint as new versions gets released. I just have to point the respective git submodules to the latest tag, push and the CI do the rest (including uploading to PyPI when the commit is tagged).
@texhex this may open up the possibility to script a Windows specific build process that does not rely on dependencies other than Python if this is something that you might have an interest in. Shall we tackle it sometime in the new year? This would definitely open up the project to developers on Windows who might have an interest in contributing here (or who want to build from source for any other reason- derivatives, etc)
@texhex this might also be the way to automate the Windows installer so that it is not necessary to manually add new builds with releases. The installer could point to the master branch HEAD and build on Appveyor? Something along those lines.
@chrissimpkins Given all the stuff you explained during the 3.001 hinting issues, and as I understood next to nothing what what happening there, I think I pass building the TTF font directly. You continue to build that beautiful font, while I try to do my best to help Windows understand that Hack has to be installed correctly ;-).
