[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Vector format/metafile for KOffice (Re: [Karbon14] misc)
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-10-31 8:43:19
[Download RAW message or body]

> |  The question is: is KSVG or some other current SVG implementation in
KDE
> |  useful for implementing the missing features for SVG support, i.e.
> | something like KoPictureSVG and kimageio_svg?

> My tests demonstrated that KSVG is slower than librsvg2 (by factor of
2x-4x),
> but KSVG is stil reasonably fast for making previews.
> Unless you have *a lot* of SVG drawings in one folder.
> But, *both of them* fail on some tests!..  So, both need fixes...
> Question is which one can be fixed faster.

The current KSVG doesn't just render, IMHO. It has a fixed goal, namely to
provide
a SVG KPart. There exist other SVG implementation for KDE.
I think the near term goal for these should be that all different SVG
implementations should use a reuseable set of functionality, namely

- a XML parser, this is provided by Qt.
- a SVGPath parser, this already exists
- a render interface with backends, at first using libart, to different
specific output devices, like QWidget, QImage - this allows that the render
system can be used by all implementeations, if needed. The base of this
render interface should be Karbons VPainter, with some help of ksvgs
SVGPainter perhaps
- an CSS (syntax) parser, which provides a SAX like API to CSS data. These
SAX like events can then be used for different purposes, like including it
into a DOM tree.
- external references resolution, this could be done by the current KIO
framework I think.

If you have other module propositions, please speak.

If these modules exist, they should be packaged into kdelibs, IMHO. If that
happens, the current SVG implementations could be changed into using this
shared functionality, this could also mean that the shared modules have to
be adapted.
If the existing implementations are done, the missing elements of KDE
support for SVG can be implemented.

Is this ok?

I think this would allow for a more modular approach than using rsvg as a
black box implementation.

Regards
Dirk







_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]