gfx: font: Begin DWrite (Windows) backend. (W.I.P.)

[TUSF]

Starting with a Font Manager that handles font discovery. That way applications don't need to bundle fonts with them.

This is still a work in progress. I just wanted to get this on a PR, and get some feedback on the API and the like. I also want to get further along, so I have a good idea of how much of the DWrite API I should prune from the win32.zig file—the current file is the entire dwrite API, but I expect I'll need to include parts of the Direct2D API when I get to font rendering, so I want to clean up as much of the unused API as I can later on. Thankfully I can probably remove any unused function's declaration and replace their vtable field with *anyopaque.

I have a couple of questions:

• What's the oldest version of windows we want to support?
• How do we want user's of the module to input font properties for matching?
  • It looks like the Text.Style type describes font weight as an integer, where 400 is "normal". That shows up in CSS, and a few other places like OpenType's internals, but it looks like for matching, most discovery APIs use something closer to the "Common" names. FontConfig for example has constants named after those, and their underlying numeric value does not match up with the numeric weights.
  • There's also the italics field, which is a bool. I'd use a slant field corresponding to an enum {normal, oblique, italic}, which more closely lines up with system APIs.

Ultimately, I'm still looking through the current work done, but wanted to contribute what I had so far, while giving my feedback on the current state of things.

• [X] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

[emidoots]

What's the oldest version of windows we want to support?

All hardware released in the last 5 years. Windows 10 was released in 2015, so we are in the clear to depend on it.

it looks like for matching, most discovery APIs use something closer to the "Common" names. FontConfig for example has constants named after those, and their underlying numeric value does not match up with the numeric weights.

OpenType Variable Fonts are a thing, and losing that functionality would be a shame. Why not just map numeric ranges to the 'common names' when needed? e.g. if someone gives a font weight of 520, then that's closest to Medium so assume that during discovery

There's also the italics field, which is a bool. I'd use a slant field corresponding to an enum {normal, oblique, italic}, which more closely lines up with system APIs.

I doubt most people know what font slant means compared to italic (which almost every text editor UI has a single toggle button for today), obliques are relatively rare/obscure compared to italics, and also you'd probably want an angle degrees parameter to go with obliques.

I should note: Text.zig is structured in our ECS, I imagine most of the stuff you are doing to be done outside this file (it's just a user of this font API) - one aspect of Text.zig / the ECS is that types need to be restricted to things that are easy to serialize/communicate in, say, a GUI editor in the future.

In any case, my suggestion would be for Text.zig to not expose this functionality for now - and in the future maybe expose a searate oblique: f32, // degrees parameter which is considered independently.