Proposal: Promote svg support

[jaham at gmx.net]

On Sunday 26 June 2011 05:10:27 Thorsten Zachmann wrote:
> On Saturday, June 25, 2011 19:45:17 jaham at gmx.net wrote:
> > Hi folks...
> > 
> > Before starting on this project I wanted to get some opinions from you if
> > that is something to attempt or if that is utter bullshit.
> 
> I'm all for it.
> 
> > I want to make a proposal to move the svg supporting classes now residing
> > in calligra/filters/karbon/svg to a lib in calligra/libs/svg.
> 
> > You may ask why I want to do that. The following are some reasons:
> I have some technical questions. I think we need support for svg at flake
> level (as there is already at the moment). How do you see those to work
> together with the svg lib? Would it be needed that the svg becomes part of
> flake or is it possible to have it in a separate lib flake depends on?

I thought to have a separate lib similar to our odf lib containing the classes 
used for loading/saving svg. One of these classes would be an interface which 
shapes can implement to save/load svg data, i.e. calling it SvgSerializable.

class SvgSerializable
{
public:
	virtual bool saveSvg(SvgSavingContext &context) = 0;
	virtual bool loadSvg(SvgLoadingContext &context) = 0;
	// some more required functions
};

The saving method could even have a default implemention which could work for 
all shapes using a svg:switch. The svg:switch can be used to put non svg data 
(e.g. odf data) into an svg file and provide a fallback image for other svg 
applications.
So each shape can choose to implement tha interface to provide native svg 
saving and loading. There are already several shape which are candidates:
RectangleShape, EllipseShape, PictureShape, ArtisticTextShape, KoPathShape.
These can be saved to svg without data loss.

> 
> Also how do you see use of an embedded svg object. Is it like the picture
> shape? Then I guess it makes sense in the very long long run to also make
> the vector shape to convert into the same datastructures so it can save
> svg. I guess that will also speed it up compared to recreate it as it is
> done at the moment. That is not something I think needs to be done now but
> it should be kept in mind when making svg more prominent.

Well I think there are different usecases for our different applications. I 
think for e.g. Karbon it is best to parse these embedded svg document into our 
shapes so that they can be edited. Otherwise I could save for instance the 
artistic text shape to odf, but cannot edit that shape after loading that file 
again. For other applications like words it would probably make sense to keep 
using the VectorShape for embedded vector content.

Ciao Jan