How did that get there? I obviously ran the test to generate the output,
so where did it spring as it is the old version of the function?
From 16364768d7.
Mysteries will never cease.
halo uses text_path + stroke + (fill | show_text) to generate a "halo"
around the string. This is to try to replicate a bug described by Ian
Britten in the PDF backend where the rendering of the show_text looked
distorted compared to the stroke.
make distcheck complains of remanents being left under test/ after a
clean, notably the files used to check the capabilities of a similar
surface and the fallback-resolution output.
Specifying individual tests to run is more common than using a group
chosen from a keyword, so change the default matching mode and introduce
'-k' to select by keyword.
A couple of different shapes that aim to test the tessellation side of
the rasterisers more... And worryingly there does seem to be an
unexpected systematic error.
In order to support blend modes, we need to use a clear background
whilst rendering the PDF, which inspired the use of DEST_OVER to avoid
having to render to an intermediate surface. However, the adjunct of
using subpixel text means that we cannot simply using the alpha channel
as the sole mask and so need to render to an intermediate and paint it
over an opaque background.
This reverts commit 506b2ebe71.
We have conflicting requirements here. In order to support extended
blend modes correctly we need to use DEST_OVER, at the expense of
supporting subpixel text. More thought required.
Using DEST_OVER in this form to paint the background white fails in the
presence of subpixel geometry (particular text), so remove the hack and
simply paint the background white prior to passing the surface to
poppler. KISS.
This test case should be much clearer than half-coverage over what it
purports to actually test. In each pixel, it draws a single geometric
primitive that coverages a known percentage of the pixel and then we
measure how close the rasterisers are to that ideal.
Hitting an error in a test case is almost as bad as crashing, and the
severity may be lost amidst "normal" failures. So introduce a new class
of ERROR so that we can immediately spot these during a test run, and
appropriately log them afterwards.
Add some overlapping triangles (coarse enough for them to be resolved
using Cairo's 24.8 fixed point without loss of precision) to exercise
handling of overlapping subpixel geometry.
Hmm, red over red makes the test pointless. The test still remains of
highly dubious quality, as it primarily serves as a rendercheck more
than a test of Cairo. The best hope for this test is that it inspires a
better one.
And incorporate the notes made by Joonas.
Add tests for degeneratate linear gradients (with start point equal
to the end point), degenerate radial gradients (start radius and end
radius equal to zero, same start and end circle) and gradients (both
linear and radial) with just a single stop.
