Qt SVG renderer

[Matthew Woehlke]

Richard Dale wrote:
> On Thursday 31 July 2008 19:31:46 Matthew Woehlke wrote:
>> Well *I'm* still curious. So I dug out where in svn the .svg's are...
>> and at least for media-flash-memory-stick, there is indeed *not* junk in
>> the file... all the background garbage is indeed the fault of the
>> renderer, not the svg. (I wonder if Ariya might be onto something, if
>> maybe something is being reused without being cleared, rather than a Qt
>> problem. I must admit, it's hard to imagine how Qt would manage to
>> render bunches of other icons behind the 'right' one.)
>
> I think the images were generated with a QtRuby program as I helped ruphy get 
> it working on the #plasma irc channel. Sorry this has only just occured to 
> me, although I've been reading the thread.
> 
> It renders all the "*.svg"s in a directory to .pngs. However, if I've just run 
> it with just a single svg at a time, and I get different results. So I 
> suspect this a more likely a bug in QtRuby than Qt itself.

Ok, then there is definitely something going wrong that isn't a 
"rendering" problem in QtSvg. That's valuable debugging information. 
(But comparing to a C++ version would be good, it may be that QtSvg is 
holding on to parts of old svg's.)

> So I think we should do the same thing with a C++ program before reporting any 
> bugs to Trolltech/Nokia.

Sounds like a good idea. Of course, we do still know QtSvg is missing 
features we want to be able to use, mostly masking and blur :-).

At any rate, from Thiago's last message it sounds like we've got the 
ball rolling, and TT has their own in-house tool that is also showing 
discrepancies, so I'm thinking they probably have a good idea now what 
(render-wise) isn't working.

As above, I think tracking down the 'extra garbage' issue could still be 
useful, to determine if it's on the ruby end or in QtSvg/QPainter. 
(Maybe it's even in the XML parser :-).)

-- 
Matthew
FOSS: Giving people the cage and it's blueprints, gratis. The "L" matters.