[cairo] rendering changes cairo 1.16 -> 1.17.4
hlewin at gmx.de
Sun Feb 28 22:32:15 UTC 2021
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:
> 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 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
> 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:
> 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.)
More information about the cairo