GeezerVison

Awesome to see work on the text-stuff!
Some questions:
a) Could you expand the point why ctypes or cffi wouldn't work? From an maintenance pov these are much easier to handle.
b) After looking at the code this seem to be a perfect match for cython, or am i wrong here?
c) I toyed around with idea of using the internal freetype-cache system for matplotlib, would that be supported?

Thanks for all the and sorry if this sounds too critical.

a) Could you expand the point why ctypes or cffi wouldn't work? From an maintenance pov these are much easier to handle.

ctypes and cffi both create a major security hole since one can basically open any library and call any address in it, so they are not available in restricted execution environments such as Google App Engine. With the whole world going to containers, I suppose that will become less of an issue over time, but in the meantime, we can't really decrease the number of platforms that matplotlib can run in.

b) After looking at the code this seem to be a perfect match for cython, or am i wrong here?

I actually tried and failed with Cython initially for these wrappers. The very careful memory management required for freetype and the stuff like the FT_OpenArgs with its C callbacks etc. really is far more cumbersome in Cython than in direct C. Plus, Cython requires copying all of the information in the FreeType headers over which is a real pain when trying to support multiple versions of FreeType. For example, FreeType explicitly says to not rely on the numeric values of error codes -- but in Cython we would have to copy those numbers over and then keep them in sync with each revision of FreeType. The FreeType API also provides a lot of things through direct access in structs. Again, as those structures change, a Cython wrapper would potentially have to account for changes in those structs over time. With C, a simple recompile will do.

Above all that, I find Cython really hard to deal with when things go wrong. Trying to run gdb or valgrind over that stuff is a nightmare.

Of course, all of this comes from a bias of being very comfortable with C.

c) I toyed around with idea of using the internal freetype-cache system for matplotlib, would that be supported?

I haven't wrapped any of FreeType's cache stuff. It certainly could be added in this scheme. It doesn't look super useful in a Python context since it's so easy to implement cache-like behavior, and it's reference counted etc. However, it might be the case that FreeType's cache code has less overhead etc. I think I would start by seeing just how much time is spent re-doing work to get a theoretical "best case" for using caching before devoting the considerable effort to use this stuff.

Will this also obsolete #3912?

Will this also obsolete #3912?

This will provide an avenue for handling TTC files in the correct and general way. Probably will do that as a follow-on to this PR, however.

I've punted on checkbox #1 in the original topic. FreeType can only manage the metrics in an AFM file if you have an associated PFB file -- which we don't ship or need to ship. I think the status quo (using afm.py) is fine there for now. It supports what is now a sort of niche use case (generating PostScript files using only the core 14 fonts).

For the record FreeType is already using a unicode charmap by default (http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftobjs.c#n1370); since FreeType 2.8.1 such a charmap will be automatically generated if the font doesn't include it (https://sourceforge.net/projects/freetype/files/freetype2/2.8.1/). So the second point will become moot once we switch the vendored FT version to >=2.8.1.

Closing in lieu of #9763

Actually there's (at least) still one thing that this PR does which #9763 doesn't, which is to replace ttconv (the font subsetter for pdf/ps output). That's actually a task fairly independent from wrapping freetype (which is what #9763 focuses on).

Opened issue about ttconv and closing this again.