WPT-compatible tests?

[progers]

This is a fantastic test suite! Have you considered writing future tests that are compatible with WPT reftests (link) and upstreaming them to wpt? WPT tests are bi-directionally synced into Chromium/Webkit/Gecko's repositories, and by sharing tests, we can improve interoperability between implementations.

An example test is svg/text/reftests/no-background.svg and svg/text/reftests/no-background-ref.svg. I have been committing SVG WPT tests in .html format, but wouldn't mind switching to .svg if it would help non-browser implementations.

[RazrFalcon]

Aren't WPT uses HTML? Those tests cannot be used by pure SVG libraries. That's why resvg has its own tests.

Also, this test suite uses SVG-to-PNG tests, while WPT uses some other method? No idea.

I did looked into WPT long time ago, so I'm maybe missing something.

[progers]

WPT can use either .html or .svg, and no-background.svg is a random example of a .svg test in the WPT repository. Many of the SVG tests in WPT do use HTML, but I think it would be okay to script bulk-convert the ones not using HTML features to .svg. Having implementations that work the same way (we call this "interoperability") is critical to the success of SVG.

If you think there could be some value in this area, I'd be willing to take one of the examples from your book and add it as a WPT test, and we could see what happens.

[RazrFalcon]

I don't understand how WPT checks that a test have passed. Is it automated? Is there an expected output file? I see -ref files, but those are SVG as well, which is pointless. I don't understand how it would work for complex cases, like filters. Can you clarify it?

Either way, the idea seems interesting, but I have no time working on it. Not to mention that is seems like my test suite has far more tests, so it would be mostly a one way transition. And I cannot use WPT anyway, because there are no reference images (afaiu). It would be nice to reduce fragmentation, but I don't see how it can be done in a way that would satisfy everyone.

Having implementations that work the same way (we call this "interoperability") is critical to the success of SVG.

Well, I work with SVG long enough to know that it would never happen. Reproducible SVG rendering is a myth. You cannot even draw a simple path reliably, forget about more complex features like clipping, masking, filters and text. The only solution here is an SVG spec subset or an automated tool to dumb down an input SVG (kinda like usvg, but actually working).