Responding to all the scattered bits of this thread I know something about...
> Skia: https://github.com/google/skia/tree/master/third_party/freetype2 > modules: no raster1, type1, pfr, bitmapped formats > options: seems to be using the default, i.e. no subpixel rendering, no > harfbuzz, no adobe glyph list I wouldn't look too hard at the Skia one, it's set up that way for odd testing reasons and isn't really part of a Skia release. You'd probably be more interested in how FreeType is built and used by the Android Open Source Project [0] (though always out of date) and by Chromium [1]. Note that they both use their own build system. [0] https://android.googlesource.com/platform/external/freetype/+/refs/heads/master/Android.bp [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/freetype/BUILD.gn > Well, we need a different corpus for rendering testing – I think > we should use what Chromium currently uses. > Chromium itself currently uses checked in images and a bunch of custom scripts to go with the builders to detect pixel changes. They're actually looking to move to something a bit better. It's just difficult to change a big thing like that in Chromium. > 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 :-) Note that Chromium doesn't just do live testing of FreeType, Chromium actually stays at FreeType tip of tree. (Note that Chrome always ships with a statically linked fairly recent FreeType; Chromium can be built with FreeType either statically or dynamically linked; some distros build Chromium to use the dynamically linked system libfreetype6.so.) It generally takes ~4 hours from the time a FreeType commit is made to run all the Chromium bots with the new FreeType and then a manual approval [2]. Chromium has enough in it's third_party directory to be a distro by itself and tries to solve the distro type issues by just staying at tip of tree (and since it's all internal doesn't need the API / ABI stability). My earlier comments about releases and distros have a lot more to do with the Chromium (not Chrome) builds the distros do, since the Chromium bug tracker sometimes gets reports about an old FreeType in the distro misbehaving [3][4]. These are examples of things that would have been nice to cherry-pick in a FreeType branch and just let the distros pick up. Chromium somewhat needs to be at FreeType tip of tree anyway for all the fuzzing, as Chromium also runs the FreeType fuzzers and a few others in addition that fuzz FreeType (independent of ossfuzz). Since keeping up to date is now automated, far from trying to be rid of it, we actually like it. [2] https://autoroll.skia.org/r/freetype-chromium [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932303 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929982 There are probably several dimensions to explore from this, from the simplest things to full goodies like Skia Gold > <https://skia.org/dev/testing/skiagold> which is really impressive, can be used for non-Skia projects, but requires setting up / administering / paying for Google-Cloud accounts / services. If you're interested in Skia's Gold project I can put you in touch with the maintainers. They are interested in making it more easily available and run on more generic platforms.
