Add concept of working memory formats to filters (was: Re: Initial work on a Karbon CDR import filter)

[Friedrich W. H. Kossebau]

Am Samstag, 28. Januar 2012, 11:04:54 schrieb Boudewijn Rempt:
> > Some questions:
> > Initially I tried to create directly a KarbonDocument object, not
> > another SVG file. But then I found out that shapes like e.g. Rectangle
> > and Ellipsis are only provided by factories from plugins, so I cannot
> > create them directly from code, is that correct? Do I really have to
> > instead create a SVG file as output?
> 
> In general, it's really better to generate SVG and save that. It's possible
> to directly create shapes by getting the right factory from the registry
> and so on, but that's complicated and fragile; leave that job to Karbon
> itself. Most filters generate files in the application's native format.
> 
> The exceptions are Krita and the excel import filter for Tables; krita
> because raster image files are often huge and having an intermediate step
> would lead to performance problems (and also for historical reasons, it's
> always been this way). The excel filter directly fills a Tables document
> mostly for the same reason.

Hm, okay, will turn to stream some SVG for now then.

Now, creating a KoXmlDocument in the CDR filter, then streaming the result, 
just to create another KoXmlDocument in the SVG filter, this makes the 
resource-saver inside me scream a little.

What about having KoFilterChain::outputDocument() give me some e.g. 
CaSvgDocument (new subclass of KoDocument) which could then transport the 
KoXmlDocument to the SVG import filter, which takes it from the 
KoFilterChain::inputDocument()? Are the filters living in the same process, so 
this is doable?

This would need also a change or rather fix to the description of the input 
and output of the filters. E.g. the Karbon SVG Import Filter has
	X-KDE-Export=application/vnd.oasis.opendocument.graphics
	X-KDE-Import=image/svg+xml
But in reality the filter does not create a byte stream of the format 
"application/vnd.oasis.opendocument.graphics" but a working memory structure 
of the format "KarbonPart" (well, or rather fills it).

I would propose to fix this in the filter description and allow to define also 
the working memory models which are accepted. The CDR import filter would have
	X-KDE-Import=application/vnd.corel-draw
	X-KDE-Export=Calligra/SvgDocument
and the SVG import filter would have
	X-KDE-Import=image/svg+xml,Calligra/SvgDocument
	X-KDE-Export=Calligra/KarbonDocument
and would try to get a SVGDocument from inputDocument() if the "from" 
parameter is "Calligra/SvgDocument".

To turn the KarbonPart/KarbonDocument into a stream there would be a separate 
filter which has
	X-KDE-Import=Calligra/KarbonDocument
	X-KDE-Export=application/vnd.oasis.opendocument.graphics

What do you think? Worthwhile to try to implement? Other ideas?

Cheers
Friedrich