Somewhat continuing my previous post. I cannot quite decide whether to use the pure-Go rewrite of freetype from the Go team (somewhat old, and also seems to have not been updated since 2017; but seems to be actively used by some nonetheless) at https://github.com/golang/freetype , or current C freetype to look at how to do ftdump.
Since I know I have to use C freetype for the FontVal-related functionalities, so I have done that first. The Go cgo facility can consume C library headers directly, and Go can use C typedefs directly, so it is easier to _start_ with Go to interact with C-based libraries, compared to python's ctypes. Then the situation is different and somewhat downhill. Compare the python version and the go version of the same thing, quite similar in size: https://github.com/FontVal-extras/freetype-py/blob/fontval-diag/examples/font-diag.py https://github.com/FontVal-extras/freetype2-demos.go/blob/master/font-diag.go FT_Int , FT_F26Dot6 , FT_UInt, FT_Int32 are all different types in Go. It is also difficult/ugly to do anything involving (void *), which C freetype uses quite frequently, in Go. See the "unsafe.Pointer" stuff in the Go code. Go's own "int" type is 64-bit, so requires explicit casts to C.int in either directions in quite a few instances, in loop counts, for example. I was stuck on one single extra white space character for about a day, for exporting go routines as C function pointer callbacks... (I filed a documentation bug / feature request for this at https://github.com/golang/go/issues/56853 ). Anyway, here are the 3 versions of a similar program in Python, Perl and Go: https://github.com/FontVal-extras/freetype-py/blob/fontval-diag/examples/font-diag.py https://github.com/FontVal-extras/p5-Font-FreeType/blob/font-diag/examples/font-diag.pl https://github.com/FontVal-extras/freetype2-demos.go/blob/master/font-diag.go The C# version of same sort of code is in HinTak/Font-Validator/Compat/Compat.cs . The RX branch is evolving to go back to using the proprietary Microsoft backend: https://github.com/FontVal-extras/FontVal-RX/blob/main/Compat/Compat.cs typeless (void *) pointers and function pointer callbacks are some of the difficult issues with using FreeType in a non-C language. The latter also come naturally with font editor types of usage. This explains a bit why the go people decided to re-write FreeType in pure-go (instead of putting out a Go-friendly wrapper around C Freetype) - some of C FreeType is rather Go-unfriendly.
