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,
https://typedesign.netlify.app/tdrenderer.html) 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!
What are we supposed to answer to your post exactly? The bitmap you posted has little context that explains how it was generated (in particular how you configured the TrueType interpreter for FreeType), or what we're supposed to see as defects (hint: when it comes to vector graphics rendering: differences != defects).
The web page you link to mentions that your code is buggy anyway. We spent a lot of time tuning the TrueType interpreter and the monochrome rasterizer, trying to match the bi-level rendering of Windows for popular / well-known fonts (e.g. Arial), but we do not guarantee that rendering results will be 100% identical for all fonts, since some of the geometric computations performed during bytecode execution have varying level of accuracy / rounding behaviour, depending on their exact implementation details (which have never been part of the spec). However, if you think we are wrong, we would be happy to see you research on the topic explaining how to improve things in the code base, so we can answer to your claims on a technical basis.
I'm sorry if you thought that FreeType would match rendering 100% of the time, we never made this claim, even if we try very hard. Of course, you're free to help us improve the situation.
- David