Proposal: Promote svg support

[jaham at gmx.net]

On Sunday 26 June 2011 02:35:17 Aakriti Gupta wrote:
> On Sun, Jun 26, 2011 at 5:02 AM, C. Boemann <cbo at boemann.dk> wrote:
> > On Saturday 25 June 2011 19:45:17 jaham at gmx.net wrote:
> > > Hi folks...
> > > 
> > > 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:
> > > 
> > > 1. Make it possible to have support for loading and saving embedded svg
> > > documents in odf files.
> > > 
> > > 2. Support for copy-pasting in svg format.
> > > 
> > > 3. Some shapes may optionally support to save directly to svg via an
> > > Interface (i.e. SvgSerializable) to implement.
> > > 
> > > 4. Allow other application to add svg file format support easily.
> > > 
> > > The first and third point is especially important for the artistic text
> > > shape. After improving that shape a lot it became clear that there is
> > > no way to represent that shape in odf. So I had to remove the old
> > > insuffient loading/saving code. This has two consequences:
> > > a) the shape can not be saved to odf,
> > > b) copy-pasting of that shape does not work.
> > > This has to be fixed.
> > > 
> > > So my intention is to create a svg lib which helps implement the 3
> > > points above and thus move the svg support to a more prominent
> > > position.
> > > 
> > > 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.
> > > 
> > > Hope to hear from you
> > > Ciao Jan
> > > 
> > > _______________________________________________
> > > calligra-devel mailing list
> > > calligra-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/calligra-devel
> > 
> > I think it makes total sense

> Some of these ideas are close to my GSoC project.
> I am working on a new mode in Stage for making animated SVGs. For this a
> lot of the stuff in filters/karbon/svg needed to be re-used.
> 
> I have already ported the common classes to filters/libsvg (which I
> created) and made the classes SvgParser and SvgWriter generic. Now
> additional application data can be added to and read from an SVG doc.
> 
> I have tested the use of these in Karbon and also for application specific
> data of Stage. Works fine for me and I have sent out a patch to Thorsten
> for a review too.
> 

What I plan to change is that the writing of the svg content is moved to the 
shape level. Having the svg parser and svg writer know about the internals of 
a shape is not a clean design. For instance now the writer and parser have to 
include the different header files of the shape which it needs to know about. 
Some of these shapes are plugins which makes that even uglier.
In the future, the parser and writer only need to dynamic_cast to an 
interface, i.e. SvgSerializable (see my other mail on that) to actually be 
able to save or load a shape to or form svg. (Ok one thing is still missing, 
the individual shape factories should have the information which svg tag a 
specific shape can load, like we do for the odf tags now)
I promise to make it possible for you to keep writing your animation specific 
data to svg. As I will work that out in a branch first, there is nothing for 
you to worry about for your gsoc project.

Ciao Jan