search

google / iconvg

IconVG is a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji.
Apache License 2.0
676 stars 11 forks source link

Canonical unit tests #10

Open Hixie opened 3 years ago

Hixie commented 3 years ago

It would be great if the spec had a bunch of canonical test cases in some unambiguous format (something not prone to variations in antialiasing etc). This could be done for some aspects of the decoding, e.g. given an input custom palette, what does CREG contain at the start of execution, or given an IconVG file consisting only of styling opcodes, what are the values in the registers, viewBox, etc, at the end of execution.

Hixie commented 3 years ago

Some canonical error handling tests (e.g. checking that the metadata parser doesn't allow out-of-order blocks or duplicate blocks, handles unknown blocks, handles NaN appropriately, etc) would be great too. These would likely fall into two groups: files that should not render, and files that should render.

Hixie commented 3 years ago

Given https://github.com/google/iconvg/issues/19 it would be possible to create unit tests that verify the x/y, cx/cy, and last-drawing-command registers too.

nigeltao commented 3 years ago

some unambiguous format (something not prone to variations in antialiasing etc)

The iconvg_canvas__make_debug output isn't exactly the same thing, but it's at the op level, not the pixel level, so isn't affected by anti-aliasing settings, or vector rasterization algorithms in general. It might make the basis of an unambiguous golden test format.

$ ./build-example-with-cairo.sh 
Building gen/bin/iconvg-to-png-with-cairo
Building gen/bin/iconvg-viewer-with-cairo
$ gen/bin/iconvg-to-png-with-cairo test/data/action-info.hires.ivg > /dev/null
debug: begin_decode({0, 0, 256, 256})
debug: on_metadata_viewbox({-24, -24, 24, 24})
debug: on_metadata_suggested_palette(...)
debug: begin_drawing()
debug: begin_path(128, 21.3333)
debug: path_cube_to(69.0667, 21.3333, 21.3333, 69.0667, 21.3333, 128)
debug: path_cube_to(21.3333, 186.933, 69.0667, 234.667, 128, 234.667)
debug: path_cube_to(186.933, 234.667, 234.667, 186.933, 234.667, 128)
debug: path_cube_to(234.667, 69.0667, 186.933, 21.3333, 128, 21.3333)
debug: end_path()
debug: begin_path(138.667, 181.333)
debug: path_line_to(117.333, 181.333)
debug: path_line_to(117.333, 117.333)
debug: path_line_to(138.667, 117.333)
debug: path_line_to(138.667, 181.333)
debug: end_path()
debug: begin_path(138.667, 96)
debug: path_line_to(117.333, 96)
debug: path_line_to(117.333, 74.6667)
debug: path_line_to(138.667, 74.6667)
debug: path_line_to(138.667, 96)
debug: end_path()
debug: end_drawing(flat_color{00:00:00:FF})
debug: end_decode(NULL, 73, 0)

The gen/bin/iconvg-to-png-with-etc program automatically prints such output to stderr. I have a TODO to make this optional (as a -debug command line argument).

The coordinates printed here are also in dst-space, not src-space, which would probably need tweaking for golden output. Or we could size the dst rectangle to equal the src viewBox.

Hixie commented 3 years ago

we'd have to define the precise format (e.g. down to e.g. number of sigfigs) but having a test suite like this would be very interesting for new implementations.