<div dir="ltr">There may also be an interesting machine learning problem here to use a more intelligent criteria for determining if an image has failed.<div><br></div><div>By changing the freetype version we have a bunch of images that do fail pixel comparison that should not and by slightly modifying tests or shuffling the test <-> result image  mapping we can generate as many do fail and should fail cases as we need.</div><div><br></div><div>Tom</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 11, 2017 at 1:40 AM Antony Lee <<a href="mailto:antony.lee@berkeley.edu">antony.lee@berkeley.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>1. Sticking to testing with the old FreeType.</div><div><br></div><div>Injecting an older FreeType version is "relatively" easy to do (the question is whether you want to do it...).  Naively, one could just set LD_PRELOAD to /path/to/libfreetype.so, but that will also affect subprocesses such as imagemagick, which (IIRC) don't like that, so instead the correct way is to ensure that the Python process calls `dlopen('/path/to/libfreetype.so', RTLD_GLOBAL)` which forces symbol resolution *in this process* to first check the given path, but does not affect subprocess (alternatively, one could remove LD_PRELOAD from the environment before calling the subprocess but that seems messier).  Fortunately, dlopen is "effectively" available under the name of `ctypes.CDLL` in Python.</div><div><br></div><div>I have a proof of principle somewhere that patches the testing framework to 1) ensure that an old freetype is built (basically moving the local_freetype implemenation from setupext to the main lib), and 2) loads it as above.</div><div><br></div><div>Another relevant issue is the manylinux wheels, which must somehow embed a libfreetype.  Currently I believe this is done via static linking.  This is not so great if you also want to load freetype for other reasons; for example mplcairo (which loads freetype via cairo) currently cannot work with local_freetype builds due to symbol conflicts.  I believe that switching to the standard manylinux approach (which is to include the shared object in a hidden folder and set RPATH appropriately) would work better (and allow us to strip out the static linking code).</div><div><br></div><div>2. Switching to newer FreeTypes.</div><div><br></div><div>I don't think committing all test images to the main repo is really a viable option: FreeType is also making new releases every once in a while and different Linuxes have different versions (<a href="https://pkgs.org/download/freetype" target="_blank">https://pkgs.org/download/freetype</a> gives 2.8.1 (Arch, Debian Sid), 2.8 (Fedora 27, Ubuntu 17.10), 2.6.3 (Debian 9, OpenSUSE 42.3), 2.6.1 (Ubuntu 16.04 LTS) and that's only a few).</div><div><br></div><div>I do believe that adding tooling that generates the test images to a side repo for each tag + FreeType version (say, using the FT versions of the major distros at the time of the tag) may be reasonable.</div><div><br></div><div>3. Side note.</div><div><br></div><div>If #9763 (or #5414) gets accepted (new FT wrappers), they will also require a new generation of the test images: ft2font currently generates "wiggly baselines" in certain cases (see example in #5414), and try as I might (i.e. not so much) I could not reproduce them in the new wrapper :-)</div></div><div dir="ltr"><div><br></div><div>Antony</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-12-10 21:44 GMT-08:00 Elliott Sales de Andrade <span dir="ltr"><<a href="mailto:quantum.analyst@gmail.com" target="_blank">quantum.analyst@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto"><div dir="ltr"><div dir="auto">Hi all,<div dir="auto"><br></div><div dir="auto">Downstream in Fedora (and maybe Debian), they are running into issues with testing and text. Fedora 26 has FreeType 2.7.1 and Fedora 27 & Rawhide has FreeType 2.8. Fedora 25 uses 2.6.5, but it will be EOL in the next week. Many other distros are also transitioning to these newer FreeType as well [1] and I think anaconda recently added 2.8 too.</div><div dir="auto"><br></div><div>With 2.7.1, a few tests fail (rms < 1) and it is straightforward to patch that [2]. With 2.8 though, over 800 tests fail [3] ranging up to ~80 rms [4]. This is a bit harder to paper over.</div><div dir="auto"><br></div><div dir="auto">I see a few ways to mitigate the problem, with varying advantages/disadvantages:</div><div dir="auto"><br></div><div dir="auto">1. Bundle the older version in the Matplotlib package like we do with tests. I don't really believe this to be a viable option for downstream, but I'm just mentioning it to be thorough. There are already a few (minor) security issues in the one we test against.</div><div dir="auto">2. Inject older FreeType just to run tests on the package. Again I don't like this idea. The point of running tests is to be sure that the version in a distro works *in that distro*. Testing with something a user could never install seems useless.</div><div dir="auto">3. Re-create all our current and future test images with 2.8. While this is most future-proof, adding over 800 images is going to bloat the repo quite a bit.</div><div dir="auto">4. Create some sort of side repo with test images for other FreeType releases. This would reduce bloat in the main repo but be somewhat more work. Thus I'd only suggest doing so for tags.</div><div dir="auto"><br></div><div dir="auto">I dislike the first two options as they would be repetitive across distros (unless they just stopped testing altogether), but the last two are not without work for us.</div><div dir="auto"><br></div><div dir="auto">Opinions? Alternative ideas?</div><div dir="auto"><br></div><div dir="auto">[1] <a href="https://repology.org/metapackage/freetype/versions" target="_blank">https://repology.org/metapackage/freetype/versions</a></div><div dir="auto">[2] <a href="https://github.com/QuLogic/matplotlib/commit/cfdc835923407810bd087f60332cdc8cdcb23f05" target="_blank">https://github.com/QuLogic/matplotlib/commit/cfdc835923407810bd087f60332cdc8cdcb23f05</a></div><div dir="auto">[3] <a href="https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log" target="_blank">https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log</a><br></div><div dir="auto">[4] <a href="https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1" target="_blank">https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1</a></div><div dir="auto"><br></div><div dir="auto">--</div><div>Elliott<br></div></div>
</div></div>
</div>
<br>_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div>