add support for building zlib and libpng libraries in setup-build-freetype.py #149
Conversation
|
I'm no sure to fully understand this PR but if @anthrotype approve, it's fine for me. @HinTak Can you have a quick look? |
|
@mammo0 Hmm, I think building with Jam has been dropped years ago. For unix and mingw builds, the export symbol list is generated by this sub-makefile (if you build via ./configure , etc). ./builds/exports.mk As for your problem /motivation for this pull - I actually do understand why you want to do this. Some emoji (I think you are talking about Apple Emoji specifically, actually!) fonts use png as the embedded bitmap format, so freetype needs to be linked with libpng to support that. As for libz, it is one of the specific compression schemes that libpng uses, so it comes as an indirect dependency at least because of needing libpng. There are 4 kinds of emoji fonts, I think - one with png embedded (Apple's), svg (Adobe/Mozilla folks), CPAL (Microsoft), CBDT (Google...). I think providing an option to statically build libpng/libz info freetype is a good idea. Hopefully it is done correctly. |
|
I am not familar with cmake enough to tell - but it is probably simple enough to just analyse the outcome - if it loads the apple emoji fonts, and does not show the png/zlib symbols under nm (on linux/mac) PE export table (for windows) , that would be fine. |
Ok, back in 2020, when I made the original PR, you used freetype version 2.10.2. That version still used the Jamfile. Now you've switched to version 2.11.0 (current master). That version uses the
Yes, you're absolutely right about this.
Thanks for supporting my idea. As I mentioned above, I will rework my PR and post a list of the exported symbols. |
-> build zlib with 'FREETYPEPY_WITH_ZLIB=1' -> build libpng with 'FREETYPEPY_WITH_LIBPNG=1'
-> on the official website only the current version can be downloaded -> so this script will break every time a new version of zlib is released -> using mirror on sourceforge
mammo0
force-pushed
the
built_in_zlib_libpng
branch
4 times, most recently
from
c025730
to
2ad6ccf
Compare
|
Ok, now I've rebased this PR to the current master branch. @HinTak regarding the problem with the re-export of symbols from included libraries: But I think I found a solution to not re-export the symbols of the embedded libraries. On Linux and Windows the linker flag Click to expandThere are no references to harfbuzz, libpng or zlib. |
|
adler32*, deflate* and zlib* are zlib (libz) symbols. I just remember zlib is treated slightly differently - freetype bundles its sources under src/gzip/ . |
|
I think I used this before |
|
Oh, you're right. Zlib is still there... Sorry about that, but it was a long debugging session yesterday. At first I globally used I will try your suggested syntax tomorrow and report back. Thanks for your patience. |
mammo0
force-pushed
the
built_in_zlib_libpng
branch
from
2ad6ccf
to
1ccdc8c
Compare
|
Ok, I already found some time today. I tested your suggested syntax with e.g. The problem with the exported zlib symbols was because of a typo. The resulting library file was nm -g libfreetype.so: |
|
maybe the ci should be set up to run this (at least on Linux), otherwise even if we merge this the code will get rotten pretty soon. A test loading a subset of an emoji font would also be nice to confirm it works at runtime as well. |
|
I agree, some tests are never a mistake. I can add a test. |
|
There are some conflicts but I'm not sure I can fix them. |
|
@rougier merged it ;) |
|
Just a historical note: the jam build mechanism is perhaps 20+ years old; ./configure && make slightly younger but not much. Yes, it looks like jam support was removed recently; and building with cmake and meson were added. And visual studio support perhaps 10 years old.
|
|
I suppose this is ready to merge after someone added a test? I think we can just ship with zlib and png deps built into the bundle by default. |
|
That depends - python (shipped by Apple or homebrew?) itself is a universal binary, right? |
On my Intel Mac the Python binary from Homebrew is only x86_64. Don't know what is it on a Silicon Mac... |
|
@mammo0 what's the status of this? |
|
I just tried to build from this branch from my M1 Pro macbook (arm64 architecture) and it seems to have worked this time, unlike the last time I tried. Maybe it's just a matter of rebasing or master and perhaps adding a small test? |
|
I also propose that, instead of building zlib and libpng only when |
|
zlib is shipped with both Windows and Mac os x as standard as far as I know. (Besides Linux). It is really libpng which is not. |
|
There is also the opposite issue, where somebody installed a bundled build, which gradually getting out dated and buggy compared to the system zlib/libpng/freetype. |
|
That's the case with skia-python until a couple of months ago - it was bundling a copy of freetype about 5 years old, and still is a problem for a few libraries inherited from the wheel-building. |
|
See kyamagu/skia-python#175 for example. |
|
we can take care of keeping everything up to date just like we do for the embedded freetype and harbuzz, it's no big deal |
|
Until you no longer work for Google, you mean? |
|
There is the option of somebody else, such as you @anthrotype , maintaining such additional functionality elsewhere, for those who needs/wants this. |
|
In Sharpfont (the C# binding to freetype), |
Currently, I use my forked version of freetype-py to build with libpng support. I tested this on my linux PC and on my Intel MacBook.
Good point. But this is a strategic decision that should be discussed among the maintainers. I think, I can not help here. |
|
@HinTak sorry, the "additional functionality" you are suggesting to maintain elsewhere, is it the bitmap color font support enabled by zlib+libpng that this PR adds, or is it the ability to pip install a precompiled freetype-py from PyPI with a bundled library that doesn't rely on system installed libraries? Because in my view the latter has had great value in enabling more users, especially on non-linux, who might not know how to compile C/C++ from source, to use freetype-py in various Python applications. I understand that you are not interested in maintaining that piece of code, but there are others like me or @madig who can take care of occasionally making sure that the published freetype-py binary wheels are up to date. And just like we keep freetype itself or harfbuzz updated, we can do the same for zlib or libpng, it's mostly a matter of changing the version number and the SHA256 hash (see #186), and from time to time updating cibuildwheel to fix various packaging bugs or support newer python versions. |
|
As I commented elsewhere, a line has to be drawn somewhere. Adding skia-python as a dependency to support OT-SVG color fonts (and COLRv1) is such a suggestion, for example. |
|
skia is not a direct dependency of freetype, zlib and libpng are. If one wants to render OT-SVG or COLRv1 one would need more than just freetype. freetype-py only exposes a Python interface to the freetype API, anything more is out of scope here. |
|
Skia-python builds everything (including skia) bundled. |
|
I would probably suggest that when you no longer work for Google and @madig no longer contracts for Google, some of this stuff needs to be removed . Probably should file an issue to keep track of your employment status :-( |
|
Just FYI, I think there is an understanding between me and skia-python's owner, that if I stop having an interest in skia-python and the COLRv1-related code starts to bit-rot, it will be removed. |
|
And dependency on libpng is optional because there is only one common font that needs it: Apple's Color Emoji. So it is arguable whether libpng should be bundled for windows build. |
That is not quite true. I'm using an unofficial ttf build of twemoji (https://git.sr.ht/~whynothugo/twemoji.ttf) which also uses png files.
This means, that freetype is generally not capable of rendering svg fonts? |
|
It just parses the table and provides hooks for an external SVG library to actually parse and render the glyphs |
|
There are two examples in the example directory, one uses pycairo and the other uses skia-python, to enhance freetype-py to use OT-SVG fonts. Twomoji.ttf also have a OT-SVG table. That's an argument to add skia-python as a dependency, actually. 😀 This is the official place for twemoji: |
Thank you for the hint :)
The work is currently continued here: https://github.com/jdecked/twemoji |
Because I renamed some branches my old PR #133 was closed by GitHub.
So I reopen it here with the correct branch names.
To continue the discussion with @HinTak from christmas 2020:
I checked again the sources to find out what symbols get exported. If I get it right the only file that creates the
ftexport.symfile with the symbols is theJamfilein the root directory of the freetype library: https://github.com/freetype/freetype/blob/132f19b779828b194b3fede187cee719785db4d8/Jamfile#L161-L193And there you can see it only exports symbols from the header files in the
includedirectory of the freetype library itself (https://github.com/freetype/freetype/tree/132f19b779828b194b3fede187cee719785db4d8/include). And this directory does not contain any external header files.So I think that wrongly exported symbols are not a problem here.
But you can put me right if I'm wrong here :)