freetype: need to expose mulfix or helpers to convert 26.6 pixel format to f32

[mitchellh]

Sorry for the screenshot instead of code sample, but in trying to use this lib instead of my own bindings, I need access to the top func which uses FT_MulFix

[emidoots]

Makes sense - will try to get this added in soon (cc @alichraghi thoughts?)

I imagine we should aim to expose a good portion of https://freetype.org/freetype2/docs/reference/ft2-computations.html

[alichraghi]

Sure. I planned to support most of the following SupportAPI parts:

• [x] Computations #428
• [x] Glyph Stroker #417
• [x] Bitmap Handling #428
• [x] Outline Processing #479
• [x] Quick retrieval of advance values #479
• [ ] Scanline Converter
• ~~List Processing~~
• ~~System Interface ( tried zig's c allocator but it crashes )~~

[mitchellh]

Thanks, I'd normally be happy to contribute this myself but wasn't sure where you wanted it or how you wanted it structured. If you do want to provide guidance like that, I can fill it in.

[alichraghi]

wow, Thank you! the structure is mostly based on freetype-rs

Files

lower-case files (expect types.zig main.zig and error.zig) are taken from freetype headers name and Upper-case files are Structs defined in header files but they were large or contains methods so moved to a seperate file (e.g. Face in freetype.zig or Outline in image.zig).

Types/Functions/etc

some struct has no method or complicated members. so for now they are just renamed c types (e.g Vector = c.FT_Vector). im just not sure if it worse to rewrite translated c functions to accept our redefined types or even use @bitCast like before. but at the end it's just for readability. other remaining structs is a layer over c structs:

// Face.zig
const Face = @This();

handle: c.FT_Face,

pub fn doSomething(self: Face) void {
  c.do_something(self.handle);
}

If you didn't find something same in binding, just do what you think is right