Qt SVG renderer

Rafael Fernández López ereslibre at kde.org
Tue Aug 5 00:07:15 BST 2008


Hi,

> what would be useful is explaining, plainly and openly, *why* this is the
> case, even if the answer comes down to "we simply don't have enough reason
> to justify investing further in this technology" or "it would be too much
> work to do otherwise".

Yes, I agree on this.

> but simply repeating ad nauseum "only support SVG Tiny" is really not
> helpful to getting this conversation to a point where there is mutual
> understanding.

Actually, you can implement special features but still not supporting the SVG 
spec fully. That would mean something like TinySVG + special features 
(masking, filters...).

> personally, i'm interested in seeing things that aren't really part of SVG
> Tiny at all, such as being able to ask "which element is at this point in
> the svg", added to the API. this is an absolute *requirement* for doing
> useful things like SVG based on screen keyboard, and is completely doable
> with the current codebase.
>
> but if there is no appetite to extend QSvgRenderer at all (iow, it's in
> pure maintenance mode) then i probably need to know now so i can plan how
> we will work with or around QSvgRenderer in plasma.

Yes, I actually have thought several times about this. How could the svg 
renderer on webkit help us ? Would be a doable (easy) way of stripping all the 
css + js things, just letting the part that is important for us and 
introducing it into kdelibs ?

Can we rely on a 3rd party library that renders SVG ?


Regards,
Rafael Fernández López.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080805/c3e20523/attachment.sig>


More information about the kde-core-devel mailing list