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

Thorsten Zachmann t.zachmann at zagge.de
Sat Jan 28 16:12:29 GMT 2012


On Saturday, January 28, 2012 16:24:58 Friedrich W. H. Kossebau wrote:
> 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.

You don't create a KoXmlDocument. A KoXmlDocument is only for reading not for 
writing. For writing one just writes out the xml without having a DOM in 
memory. See KoXmlWriter classes. This is just a class the stream out the xml 
as text.

> 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?

That is not needed the Svg filter will read the document and as said before the 
KoXmlDocument should only be used for reading a doc and not for gererating 
one.

Thorsten



More information about the calligra-devel mailing list