> The standard ppem of the test font is: 16 The standard string of the test font is: !"#$% From the image, it is evident that both FreeType and TD renderer (my own renderer that relies on FreeType but uses my own rasterizer, typedesign.netlify.app typedesign.netlify.app ) are extremely glitchy. It is very important to take research into TrueType rendering to properly simulate the Microsoft bilevel renderer because it would help render fonts correctly. The immense complexity of FreeType's rasterizer is still not enough. What a nightmare!
This is a rather bizarre post - you seems to claim that your wrote a buggy piece of software half-based on freetype, it is not working as you wish, so it is freetype's fault - instead of your own...
More specifically - while Microsoft folks won't going to specific details voluntarily on their own initiatives, but they are happy to confirm "undefined" behavior in their rendering engine and let freetype matches undefined behavior over the years/decades. So I suspect you are simply using freetype wrongly to get the results you got.
Another point: freetype tries to render well to gray, and lately even sub-pixels. If you want to get freetype to imitate Microsoft's GDI bilevel to some degree, you need to set the TrueType property to v35 (instead of the v40 default) as well as setting rendering mode to mono (gray is the default, afaik).
Thirdly, garbage in garbage out - if you intentionally make a font which exhibits undefined behavior, and expect undefined behavior to be defined, that's crazy. There are a numbers of tools which can tell you your fonts are buggy and how, and (shameless plug) - https://github.com/HinTak/Font-Validator, Google's fontbakery, apple"s font tools. I don't know why you expect undefined behavior to be defined and matching across different renderers.