> > One thing I'd like to suggest, if FreeType 3 is ever happening, is
>.> for the DebugHook to move a bit earlier in the Library struct, and
> > especially before any of the variable/adjustable sized
> > sub-structures. It makes implementing interactive font debuggers /
> > font editors with FreeType 3, and things like Fontval, in a non-C
> > language, a bit easier.
> Hmm, what exactly do you suggest? `FT_LibraryRec` is an internal
> structure not exposed to the public, so it could be changed easily
> without any backward compatibility issues.
Exactly as what I wrote - if a next major version of freetype (3) happens, and one is allowed to break backward compatibility.
FT_Library is a pointer to a FT_LibraryRec struct. golang and perl modules consumes C headers directly, so can find and set pointers some bytes away from the begging of a structure pointer. Python and C# modules gets at freetype's internal structures by maintaining a duplicate non-C description of these structures. So getting/setting members of structures some distance away from the beginning (and somewhat variable distances too) is quite hard.
I know font debugger / editor is probably a rare usage of freetype, so rarely used members of structures should go to the end (and also probably union'ed for repurposing the same bits of memory). Maybe if they are easier to access, it might encourage their usage.