On Tue, 2013-10-01 at 15:35 +0200, Krzysztof Kosiński wrote:

2013/10/1 Martin Owens <doctormo@...400...>:

...

On Tue, 2013-10-01 at 14:56 +0200, Tavmjong Bah wrote:

...

I've run the W3C SVG 1.1 2nd Edition test suite using both Inkscape 0.48 and trunk. There are quite a few improvements in test compliance with trunk but some tests show regressions:

Thanks Tavmjong,

I fixed an issue with the gradients this morning in r12646. I looked now at the svgs to some of those failures and they've improved but are still wrong.

r12648 should render objectBoundingBox patterns and gradients correctly again, so I think some of those regressions should be fixed.

The rendering is better... but still some minor problems. I've updated the images.

Tav

On 2013-10-01 17:38 +0200, Krzysztof Kosiński wrote:

2013/10/1 Tavmjong Bah <tavmjong@...8...>:

...

The rendering is better... but still some minor problems. I've updated the images.

pservers-grad-13-b shows major breakage. The rendering reverts to how it was before r12646 when it's nudged in any direction.

JFYI - this also happens with the oldest build I have archived on my current laptop, r10795: nudging the group breaks gradient rendering.

https://www.dropbox.com/sh/qg4zykdc0ljptop/mhUXGIX1uc#/

(Screenshots with r10795 and r12648 on-load, and nudged)

I have no idea what's going on at the moment, and gdb shows me some completely nonsensical output - the results of the pretty printer are different from _item_bbox and the same bbox passed down to pattern_new, even though print /r shows that they are identical...

Regards, Krzysztof

2013/10/1 Tavmjong Bah <tavmjong@...8...>:

On Tue, 2013-10-01 at 15:35 +0200, Krzysztof Kosiński wrote:

...

2013/10/1 Martin Owens <doctormo@...400...>:

...

On Tue, 2013-10-01 at 14:56 +0200, Tavmjong Bah wrote:

...

I've run the W3C SVG 1.1 2nd Edition test suite using both Inkscape 0.48 and trunk. There are quite a few improvements in test compliance with trunk but some tests show regressions:

Thanks Tavmjong,

I fixed an issue with the gradients this morning in r12646. I looked now at the svgs to some of those failures and they've improved but are still wrong.

r12648 should render objectBoundingBox patterns and gradients correctly again, so I think some of those regressions should be fixed.

The rendering is better... but still some minor problems. I've updated the images.

In r12649, pservers-grad-13-b should render correctly.

There's still the issue of the gradients going awry when the object is nudged. I think this is caused by a faulty conversion to an user space gradient - I vaguely remember seeing some code related to this.

pservers-grad-21-b is rendered wrong, because position attributes are not inherited. Inheritance for other attributes is implemented in sp-gradient.cpp, so fixing this test case isn't that hard. su_v - can you verify whether there is a bug report for this?

I haven't yet analyzed the other test cases.

Regards, Krzysztof

On 2013-10-02 01:39 +0200, Krzysztof Kosiński wrote:

2013/10/1 Tavmjong Bah <tavmjong@...8...>:

...

On Tue, 2013-10-01 at 15:35 +0200, Krzysztof Kosiński wrote:

...

2013/10/1 Martin Owens <doctormo@...400...>:

...

On Tue, 2013-10-01 at 14:56 +0200, Tavmjong Bah wrote:

...

I've run the W3C SVG 1.1 2nd Edition test suite using both Inkscape 0.48 and trunk. There are quite a few improvements in test compliance with trunk but some tests show regressions:

Thanks Tavmjong,

I fixed an issue with the gradients this morning in r12646. I looked now at the svgs to some of those failures and they've improved but are still wrong.

r12648 should render objectBoundingBox patterns and gradients correctly again, so I think some of those regressions should be fixed.

The rendering is better... but still some minor problems. I've updated the images.

In r12649, pservers-grad-13-b should render correctly.

There's still the issue of the gradients going awry when the object is nudged. I think this is caused by a faulty conversion to an user space gradient - I vaguely remember seeing some code related to this.

pservers-grad-21-b is rendered wrong, because position attributes are not inherited. Inheritance for other attributes is implemented in sp-gradient.cpp, so fixing this test case isn't that hard. su_v - can you verify whether there is a bug report for this?

The only one I found so far wrt to inhertiance of gradient attributes: - Bug #1167689 “Referenced linearGradient is not rendered properly” https://bugs.launchpad.net/inkscape/+bug/1167689

I haven't yet analyzed the other test cases.

Hi ! I've been looking at the GSOC and after solving a few problems I can run the tests now. Now I have to find out a way to update the tests.

I've set a personal branch in my launchpad account with the changes I made to the original code. https://code.launchpad.net/~neandertalspeople/+junk/inkscape-testsuite

After updating the test I'll try to find a way to automate the tests, and perform them regulaly. What do you think about that ? Any idea about how that could be done ? Maybe it is possible to set some kind of trigger when there is a commit in the launchpad inkscape trunk ?

Guiu Rocafort

2013/10/2 Tavmjong Bah <tavmjong@...8...>

On Wed, 2013-10-02 at 01:39 +0200, Krzysztof Kosiński wrote:

...

In r12649, pservers-grad-13-b should render correctly.

It does, I've updated the images at:

http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.49/htmlInkscapeHarness/pservers-g...

Thanks,

Tav

---

October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

We could also consider doing this the other way round and add the svg compliance tests into the test suite in inkscape trunk. The trunk ppa already runs tests daily or whenever trunk changes so we wouldn't need to add any new packages.

AV On 9 Oct 2013 01:53, "Martin Owens" <doctormo@...400...> wrote:

On Wed, 2013-10-09 at 00:51 +0200, Guiu Rocafort wrote:

...

After updating the test I'll try to find a way to automate the tests, and perform them regulaly. What do you think about that ? Any idea about how that could be done ? Maybe it is possible to set some kind of trigger when there is a commit in the launchpad inkscape trunk ?

I was thinking of doing something like: create a deb for the test suite, when the deb gets built, it consumes the inkscape package, runs the tests and outputs the results and any logs etc.

Then to make use of the test results (i.e. on the new website) we install the package and read the files and the logs for useful display.

The only non-technical maybe issue is using Canonical servers to run our tests. Would they complain about a deb build like that?

Martin,

---

October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Tue, 2013-10-08 at 22:18 -0400, Martin Owens wrote:

On Wed, 2013-10-09 at 02:08 +0100, Alex Valavanis wrote:

...

We could also consider doing this the other way round and add the svg compliance tests into the test suite in inkscape trunk. The trunk ppa already runs tests daily or whenever trunk changes so we wouldn't need to add any new packages.

I'm actually interested in seeing those test results if possible. I'd like to know how easy it is to gather the information for project maintenance use.

+1, I wasn't aware that there was testing being done other than that the compilation was successful.

If we formalise the svg tests, then we need to be able to get at the resulting png files too. Hopefully those can be saved somehow when the tests run.

Martin,

Tav

On Thu, 2013-10-10 at 15:12 +0100, Alex Valavanis wrote:

This will all then result in completely "hands-free" testing whenever trunk is updated. For best results, we should really try to separate the SVG tests into known-success and known-failure lists that can be put into separate good/bad lists for "make check". The automated builder will then complain at us whenever our SVG compliance level changes.

Looking at the structure of our svg tests, they do appear to have good and bad result directories. Known bad is just a matter of filling the specific directory with specifically named files and likewise known good.

Martin,

On Thu, 2013-10-10 at 16:14 +0100, Alex Valavanis wrote:

two separate executable scripts

Not yet. And while the python is pretty hairy (needs some code review) it should be possible to make it do what you want without too many issues.

Guiu, Tav; what do you think? Would it be easy enough to modify and would you like to patch it or should I?

Martin,

On 2013-10-10 19:00, Martin Owens wrote:

On Thu, 2013-10-10 at 16:14 +0100, Alex Valavanis wrote:

...

two separate executable scripts

Not yet. And while the python is pretty hairy (needs some code review) it should be possible to make it do what you want without too many issues.

Guiu, Tav; what do you think? Would it be easy enough to modify and would you like to patch it or should I?

It's not completely clear to me what you need exactly (just a change/no change answer, a number of failed/succeeded tests, ...?), but there is currently no separation between good and bad tests. In particular, a test could have (and some do have) both known good and bad references related to it.

However, you can simply pass a list of tests to perform on the commandline if you want (or use a directory, as suggested by Alex). Any results are kept track of in teststatus.json. This file gets read and updated each run (rather than replaced with new results), so it would be possible to just run tests that failed/succeeded the last time (based on a commandline option), if that's what you need. If I can be of any help (since I actually wrote that dense bit of Python code), just ask.

On 10 October 2013 19:27, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:

It's not completely clear to me what you need exactly (just a change/no change answer, a number of failed/succeeded tests, ...?), but there is currently no separation between good and bad tests. In particular, a test could have (and some do have) both known good and bad references related to it.

Basically we need scripts that return a 0 exit code if all rendering tests succeed and non-zero if something goes wrong. In this context, a "pass" means that everything in all included rendering tests works and "fail" means that something in any of the included tests didn't work. In pseudo-code:

# Approximate behaviour of runtests.py...

num_errors = 0; # Number of errors found

for i in test_list: test_succeeded = run_rendering test(i);

if( !test_succeeded): num_errors++;

return num_errors;

Again, I'm working in the dark a bit, because I haven't tried running the tests yet so I might be talking bollocks!