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 obtain the binary data for a font installed on the system, without having to locate the physical font file (if it even exists), and read that into memory.
From the 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 that spec.
That was an interesting journey and it was a lot of fun. I think, if you take a look at that documentation, and then see how I realized its concepts in this repository, you could get an idea of how I intend 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 the main actors, such as freetype.
The development of the graphics for font (glyph) rendering is explained in the referenced documentation. There were some glitches along the way, typical when documentation is not absolutely precise, however, I was able to derive the lines and curves associated with glyph outlines.
Now I needed to understand rasterization. Since the Open Source freetype seems to be pretty ubiquitous and obviously does rasterization well, I downloaded it and went to work trying to understand rasterization from its perspective.
After about a week in a deep dive into freetype, I was no further along understanding 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 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 hopefully through these projects, I'm providing examples of those concepts.
Back to this project. Actually, rasterization is not implemented in this project 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 never 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 than I want to do myself. For example, I want to understand rasterization itself, not that which is implemented behind the scenes while rendering text. That's DWrite, I wanted something I can use in any other context, thank you very much.
Others will say using Direct2D 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 integration, and through that 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.