>> My favorite pet issue I never got around to fixing: make stem >> darkening for the autohinter be as good as the CFF variant. Also, >> at least basic stem darkening for bytecode'd TTFs. > > Can you clarify what that means exactly? I think I lack context > and/or examples :-)
I leave explanations to Nikolaus :-) >> And even a basic testing framework sounds good. One could, if so >> inclined, even use https://github.com/rougier/freetype-py and use >> pytest and hypothesis to hammer out a test suite. > > I'd prefer something that tests the FreeType API directly instead, > so something based on C or C++ instead. GoogleTest seems a good > candidate for this. There are two things to test. * API and code coverage * Rendering For the latter we have a potential GSoC project proposal this year, so let's please wait until May 4th before continuing the discussion. > Another possibility is to change the way regression testing is > performed (generating MD5 directly in ftobjs.c is ... unelegant and > limited). What's the problem with MD5? The idea is to find out whether two FreeType versions render a glyph differently. I'm not aware of something simpler. It's not intended for API testing, of course. > Is there a specific corpus of font files being used currently for > regression testing? For regression testing with have Armin's project: https://github.com/freetype/freetype2-testing > Should we try to create one or improve the existing one? Well, we need a different corpus for rendering testing – I think we should use what Chromium currently uses. BTW, Chromium does a 'live' testing of FreeType, this is, the project monitors FreeType's git HEAD and reports rendering differences to Chromium developers, which in turn report to us. Of course, they would like to get rid of that eventually :-) Werner
