About my 2nd point - you did not get it: fontforge is not freetype. If you
want freetype to imitate Microsoft's bilevel rendering, please do as I
suggested. Fontforge does not have a mode of "use freetype to imitate
Microsoft's rendering", afaik. Use v35 and set rendering mode to mono.
As for the initial paragraph - it is clear from your own png posted that
freetype (in fontforge) matches Microsoft's rendering well enough, but your own
rendering does not. You need to show a lot more evidence and proof to claim
freetype is glitchy - even our Microsoft friends don't make that kind of claim!
On Thursday, 14 May 2020, 20:38:23 GMT+1, piotrunio-2...@wp.pl
<piotrunio-2...@wp.pl> wrote:
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...
It is demonstrated that neither FreeType nor my rasterizer work properly. It
shows that any renderer that isn't dependent on any Microsoft renderer is
extremely glitchy.
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).
The FreeType rendering is taken from FontForge's previews with anti-aliasing
disabled.
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.
?????
