Proposal: Promote svg support

[jaham at gmx.net]

On Tuesday 28 June 2011 06:00:43 Thorsten Zachmann wrote:
> On Monday, June 27, 2011 22:07:28 jaham at gmx.net wrote:
> > On Monday 27 June 2011 17:25:37 Thorsten Zachmann wrote:
> > > On Sunday, June 26, 2011 18:25:56 jaham at gmx.net wrote:
> > > > 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
> > > > 
> > > > };
> > > 
> > > Agreed that having a libs like the odf lib makes sense and that
> > > contains the stuff like SvgLoadingContext .... However I'm not sure if
> > > we need a class SvgSerializable. Why not just put that into KoShape
> > > directly?
> > 
> > There is no reason other than I was a little hesistant to force svg
> > loading/saving support on each shape. Instead I thought making it
> > optionally. But if there is consent about putting it directly into
> > KoShape, I have no problem with that.
> 
> Looks like I did not understand how you want to use the above. For me it
> looked like KoShape would need to inherit SvgSerializable to be able to
> implement the functions. Seems I was wrong. Maybe you can explain how that
> is should be done.

The idea was that each shape which wants to load/save svg would inherit 
SvgSerializable. So it can be done on a shape by shape decision.

Ciao Jan