The Font Manager
The Font Manager is a complete implementation of font internals and rendering. The system is totally stand-alone in that it uses no 3rd party binaries whatsoever and does not rely on Windows Specific API calls that handle fonts. Indeed, the one Windows API (wrt fonts) is a call to GetFontData() whose purpose is to read the binary data for a font installed on the system, without having to locaate the physical font file (if it even exists), and read that as a binary file into memory.
From that binary font data, I was then able to follow the OpenType 1.9.1 specification from scratch and thus arrived at a rock solid reference implementation for the spec.
That was an interesting journey and it was a lot of fun. I think, if you would look at that documentation coupled with how I realized its materials in this repository, you could get an idea of my drive to "Influence the world of Open Source".
Maybe you'll also see what I mean by "side-by-side" comparison of "how to" vs. "how not to" and by my pontification here-in about the sad state of affairs in Open Source in general and with certain of their main actors, such as freetype.
The development of the graphics for font (glyph) rendering is handled by the referenced documentation. There were some glitches along the way, typical when documentation is not absolutely precise, however, I was able to compute the lines and curves associated with glyph outlines.
Now I need to understand rasterization. Since the Open Source freetype seems to be pretty ubiquitous and obviously does rasterization really well, I downloaded it and started to work trying to understand rasterization.
After about 1 week in a deep dive into freetype, I was no further along understanding font rasterization and had no hope of actually rendering the font graphics I already knew how to define.
I should have known. This always happens. I try my utmost to read and understand software like that because I want to know how it actually works and how did "they" implement the solution. And, every single time, I get so frustrated with the sloppiness and vast unreadability and total intermingling of solution components that I just throw up my hands and say "Enough!!".. And start over completely from scratch using the root documentation (if I can find it) and get it done right from the get-go.
THAT, my friends, is 90% of why I'm in this space. I desperately need to demonstrate how software should be written and architected, and I'm providing examples of how it should be done.
Actually, rasterization is not implemented in the Font Manager after all. After a lot of trial and error with different graphics APIs (all of them native, I have no interest in using anything other than a) something in the Operating System, or b) something that I write from scatch), I finally found the one simple and perfect solution.
The Windows Direct2D system
That solution being Direct2D. I had not used that before. I have a huge amount of graphics software in OpenGL and in plain old GDI (and in GDI+), but I was unfamiliar with Direct2D. There's also a DWrite API which did exactly what I needed in terms of rasterizing text, but it also seemed to require way too much reliance on associated windows Fonts APIs. No Way, I went to a lot of trouble implementing everything font related myself, I wasn't going to let Windows API take over that stuff. To put another way, I wanted "rasterization", not "font rasterization".I have absolutely no problem using Operating System calls that perform generalized services. That's what operating systems are there to provide. What I may have problems with is when those things are "packaged" for more specific tasks that I want to do myself, thank you very much.
Others will say this locks me into a platform, on the surface, it does look that way, but that's incorrect.
When I discovered the power of Direct2D, I created yet another COM Object, the Graphics Renderer and moved ALL rendering of any kind over to it. Specifically from both the PostScript Interpreter, AND this object. Now, neither of these two do any sort of rendering at all, instead they communicate with the Graphics Renderer to do it - and that, my friends, is software intetration, and through the effort, another powerfull software system is born, eminently useful in a plethora of environments and applications.
If there's another graphics API that would be better, or on a different platform, write it. It's that simple, the Graphics Renderer could be replaced with something else with zero impact on it's current clients, that's the point of software integration.
The Font Manager Example
As with all my projects, I've written a clean and robust example showing how to use the Font Manager in your own implementation.
Even though the FontManager started out as the font tool embedded in the PostScript Interpreter, it became very clear that I needed to separate it from that project and let it become a re-usable COM object suitable for a huge range of font rendering possibilities. That is how a lot of my projects are born, they are a part of some other project, but written in such a way that they are not inextricably merged into that project. Then, when their utility in other arenas becomes obvious, it is a simple matter to separate the code bases and turn that part of it into a formal software artifact useful in a multitude of other places and applications.
It is the power of COM in particular, and software integration in general. It is unfathomable to me why oftentimes developers don't see the potential of such an approach.