[cairo] rendering changes cairo 1.16 -> 1.17.4

[Heiko Lewin]

Hello!

You are referring to commits dealing with glyph-rasterization. The
images you posted do not really seem to be concerned with glyphs at all.

Can you clarify?

Am 28.02.2021 um 23:14 schrieb Felix Schwarz:
> Hey,
>
> sorry for the late reply - real live/homeschooling/...
>
> Unfortunately I don't have a simple test case but I can reproduce this
> easily using WeasyPrint's test suite (e.g.
> weasyprint/tests/test_draw/test_float.py).
>
> WeasyPrint issue is https://github.com/Kozea/WeasyPrint/issues/1291
>
>
> I bisected the issue back to this commit:
>
> commit ea9329215d3431ded51a71b724baf0edc25ad633
> Author: Matthias Clasen <mclasen at redhat.com>
> Date:   Sat Jul 28 12:25:47 2018 +0000
>
>     image compositor: Support subpixel positioning
>
>     Support subpixel positioning with a 4x4 subpixel grid.
>
>     When compositing glyphs in the image compositor,
>     we store the subpixel phases in the high bits of the
>     glyph index. The _cairo_scaled_glyph_index() macro
>     has been updated to discard these bits. By storing
>     the phases in the glyph index, the glyph cache just
>     keeps working. When loading a glyph, the Freetype
>     font backend shifts the outline according to the
>     phases.
>
> If I revert that commit on master the tests do pass (while they fail
> when building current master - 553c19df)
>
> Does that ring a bell? Any obvious thing I should look out for?
>
>
> I noticed issue 390 ("subpixel-positioned text strings appear to have
> a row of pixels cropped out, sometimes") in gitlab:
> https://gitlab.freedesktop.org/cairo/cairo/-/issues/390
>
> That issue also mentions commit ea932921 and Dejavu (which I think
> WeasyPrint's test suite uses as well - though I think it might not be
> an issue for the failing test).
>
> Anything else I can do besides creating a simple test case? (I tried
> that before but it is quite challenging because I have to dig deep
> through various layers.)
>
> Felix