[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:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-10-31 10:11:55
[Download RAW message or body]

On Thursday 31 October 2002 11:43 am, Dirk Schönberger wrote:
|  > |  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.

All you said above is fine with me.
Can you just pick up this archive
http://freetype.newmail.ru/svg/BlueSphere-0.1.zip
and tell me, wether you can manage to get those images rendered in that 
framework in a short time (preferably, till KDE 3.1 release)

I also need gradients with multiple stop points (I tried not to use them so 
far, but they are needed for professional work!)
I am not sure wether something like this exist in PS / EPS, so it can be 
beyond your interests.
But as I said, you can achieve limits of all existing toolkits very fast, if 
youuse modern technologies (like SVG).
Anyway, we are in front of Corel. It seems Corel failed to deliver any kind of 
SVG plugin/toolkit.  And Adobe is eating Corel's lunch on Windows platform 
:-)

|
|  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.

I prefer final results.
(remember: "we deliver!")
So, if KSVG can manage to render SVG files produced by Sodipodi and Adobe 
Illustrator - I am ready to switch :-))

|
|  Regards
|  Dirk
|  _______________________________________________
|  koffice-devel mailing list
|  koffice-devel@mail.kde.org
|  http://mail.kde.org/mailman/listinfo/koffice-devel

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/


_______________________________________________
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]