W3C home > Mailing lists > Public > www-svg@w3.org > December 2016

Re: Handling slight differences in anti aliasing for SVG 2 test suite

From: Kari Pihkala <kari.pihkala@gmail.com>
Date: Fri, 23 Dec 2016 13:49:05 +0200
Message-ID: <CAE0t3MxarSNBe5rhNxUv00KMforQF778jv1d7QPii7PLvp7oEg@mail.gmail.com>
To: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
Cc: www-svg <www-svg@w3.org>, Geoffrey Sneddon <me@gsnedders.com>
2016-11-29 1:31 GMT+02:00 Nikos Andronikos <
> It’s a common problem that reference images may be very slightly different
> than the renderings for tests. This seems to be compounded
> with the ref test model for SVG.

One option is to create a test file, which shows red color if it fails. If
no red pixels are visible, then the test passes. The test doesn’t have a
reference file, only the rendered pixels are inspected for red color
(#ff0000). This is a bit similar to the use of red color in css
self-describing tests [1].

Here’s the marker test modified to show red pixels if markers are rendered
wrong. You can try it by removing the markers.

Note that this kind of tests are not exact tests, because the red
placeholders need to be few pixels smaller than what is being tested to
prevent false results caused by anti-aliasing. Also, the placeholders need
to be large enough to fill at least few full pixels in red. So, I had to
make some markers larger than in the original test.

The same approach can be used for text, which is typically problematic
because of font hinting etc. Here’s an example of text on path with red
placeholders: https://jsfiddle.net/mcp8362s/

Before starting to use this approach, you should perhaps ask browser
vendors if they want to have this kind of tests. I'm not sure if their test
systems can work with these kind of tests.


Received on Friday, 23 December 2016 11:49:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:07 UTC