From kde-core-devel Thu Aug 07 16:36:52 2008 From: Matthew Woehlke Date: Thu, 07 Aug 2008 16:36:52 +0000 To: kde-core-devel Subject: Re: Qt SVG renderer Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=121812707411190 Tor Arne Vestbø wrote: > Tor Arne Vestb� wrote: >> I'd be happy to publish the results when I'm done. > > Here are the results: > > http://chaos.troll.no/~tavestbo/svg/ Thanks for this awesome chart! As Rafael said, I'm a bit surprised that WebKit seems to be *worse* in several ways, it looks like maybe it does not support object opacity? Main issues I see in QtSvg are no masking, non-XOR path drawing not supported, and of course lack of blur. I think it would be nice if your "compare" frame was gradiated so that the dithering artifacts aren't so visible (after all, it's acceptable if QtSvg and librsvg use different dithering algorithms!). Instead of white->pixels match, black->pixels differ, maybe you could convert both to grayscale, do a subtractive overlay, and apply levels/curves to the results to enhance the differences, but still leave minor differences as light gray instead of black. I think this would give a better idea of how "close" QtSvg is (and also provide a better metric to mechanically measure correctness, i.e. if any final pixels are darker than X, flag it as a problem, but lighter than X can be treated as "good enough"). What's a little concerning are ones like application-x-executable where librsvg is clearly wrong (and, in fact, QtSvg is closer to right). Given that I've also seen some where Batik messes up (but librsvg doesn't), that says to me that inkscape is still the closest thing to a "canonical" render (or else, our svg's are wrong somehow). And then there's application-x-java-applet, for which *none* of the renders bears hardly even a passing resemblance to inkscape's rendering. -- Matthew Did you hear about the pig that makes footwear for cows? He's a real moo shoe pork.