FreeType and Go/Golang, part 2

[Hin-Tak Leung]

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.