Comments from a svg guru

[Jos van den Oever]

by Andreas Neumann on Wednesday 30/Oct/2002, @22:15
> I therefore think that the KDE team should give SVG top priority as a
> base-technology for the KDE-desktop (SVG enable all KDE-applications) and
> as an integral part of the Konqueror browser. Combined with other XML
> technology and scripting, SVG allows very useful applications and is for
> the first-time a fully documented vendor-neutral graphics format as an
> exchange format between different applications and platforms. I am very
> happy that ksvg (svg.kde.org) already exists - but I think that it should
> have more support and priority within the KDE team than it has now.

I completely agree. SVG is a very promising technology. It's a very well 
documented standard. This means that it's a good starting point for any 
application that uses vector graphics, not just Konqueror. Adding KDE support 
while following the spec strictly will enable some wonderful features in KDE.

- use SVG as a clipboard format for vector graphics.
Using an XML standard for the clipboard will improve exchange possibilities 
with other graphical applications. In the future all graphical applications 
such as OpenOffice and Gnome Office should support pasting SVG graphics and 
it would be good for KDE to set a good example.

- a general graphics/canvas widget
The SVG specification includes a DOM. This DOM is a good starting point for 
implementing SVG support (as KSVG demonstrates). Writing a canvas widget 
based on the SVG implementation would supply KDE with a generic canvas 
widget, something still missing (although there are pretty good specialized 
canvasses). The SVG spec defines a DOM level 2 which enable event handling 
which enables such an implementation.
Writing an application which allows the user to enable edit graphics would 
then be a matter of inheriting this widget and handling the events. I will go 
as far as to say that the SVG spec allows for the creation of a very generic 
widget.

- writing applications using the SVG DOM.
When KDE and GNOME have an SVG widget it's easier to port graphical 
applications between these desktop environments, since they use the same 
DOM(=API).
Every application that uses the SVG widget can easily export SVG files. These 
files are then easily importable in any KOffice application, since they'll 
have support for it too.

What's needed before this can happen?

Most importantly, good XML support needs to be available. Right now, 
kdelibs/khtml/xml has a good XML implementation. Unfortunately, it's isolated 
in khtml and there are problems using this implementation with KSVG. A dir 
structure with maybe kxml/khtml and kxml/ksvg would make much more sense. 
This is of course no trivial matter, but essential in the long run. It will 
also simplify other XML support in KDE and KOffice.

Writing a _fast_ SVG widget is a daunting task. But this is all the more 
reason to do so, because centralizing the efforts of writing a canvas class 
will only be benneficial for the development speed of all subsequent 
graphical applications as varied as games, drawing programs, plotting tools, 
icon renderers and browers parts.

Best regards, Jos van den Oever