--nextPart5347786.2csHNtmrbl
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 S=
VG=20
spec fully. That would mean something like TinySVG + special features=20
(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=20
renderer on webkit help us ? Would be a doable (easy) way of stripping all =
the=20
css + js things, just letting the part that is important for us and=20
introducing it into kdelibs ?

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


Regards,
Rafael Fern=E1ndez L=F3pez.

--nextPart5347786.2csHNtmrbl
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBIl4umck5Abj8B0HARAoEbAJ99fj5KBG9UZz0dCj90kt0ihgUxEgCg1yJL
MjK6JXgQQemY8wu/J1/5/CQ=
=ZxRc
-----END PGP SIGNATURE-----

--nextPart5347786.2csHNtmrbl--