KoFilter: working memory formats vs. storage formats

[Friedrich W. H. Kossebau]

Hi,

I have touched this problem before* but right now I have hit it directly and 
brutally. There is a real need for patches now :)

* http://lists.kde.org/?l=calligra-devel&m=132776451010818&w=2


SYMPTOM__
Create something in Calligra Flow, then select "Export..." and select as 
format PNG or JPEG, as offered.
Try to save... and see an error: "Could not save".


REASON__
Calligra Flow does not install itself a filter for PNG or JPEG. Instead there 
is a filter from the Karbon section, in filters/karbon/image, which claims to 
convert from "application/vnd.oasis.opendocument.graphics" to "image/png" and 
"image/jpeg".
Now Flow and Karbon both share "application/vnd.oasis.opendocument.graphics" 
as native format. This makes the filter chain pick up that filter from Karbon 
also for Flow.
Just, the filter code does not parse a file/stream of format 
"application/vnd.oasis.opendocument.graphics", instead it takes the 
inputDocument() from the chain, so accessing the actual format in the working 
memory, as modelled by the Karbon API. Of course this does not work if 
activated from Flow.
Cmp. ImageExport::convert(...)
--- 8< ---
    if (from != "application/vnd.oasis.opendocument.graphics") {
        return KoFilter::NotImplemented;
    }

    KoDocument * document = m_chain->inputDocument();
    if (! document)
        return KoFilter::ParsingError;

    KarbonPart * karbonPart = dynamic_cast<KarbonPart*>(document);
    if (! karbonPart)
        return KoFilter::WrongFormat;
--- 8< ---

Using the filter with "calligraconverter" works somehow,
	"calligraconverter test.odg test.png"
creates the expected file (though does not offer to e.g. select the page, ODG 
is a multi-page format). I have not yet grasped what happens in KoFilter* so 
that there is a KarbonPart instance when the filter is invoked. Guess it is 
just by pure chance that not Flow instance is created instead, right?

Is that an error in the filter which should fallback to also look for what 
"m_chain->inputFile()" holds and try to load from there?

But what is then the usage of inputDocument()?
I do see one, e.g. Flow and Karbon have different use-cases, so the filter 
might want to take that into account, e.g. with Flow offer which page to use 
(and also know which one is the current), while with Karbon there is 
(currently) no such concept of different pages. So being able to interface to 
the working memory document model (and view model) is definitely worth to 
have.


SOLUTION__
IMHO the concept of working memory (WM) formats should be added to the filter 
system. Filters which take WM formats instead of file formats as output or 
input target can then precisely define what they operate on. 

To complete the gap in the filter chain created by the new mimetypes 
describing the WM formats there would be these changes:
* each program describes in the desktop file its WM format,
  so the filter system knows about it
* additional filters which translate between the WM formats
  and the native storage formats


Now, what do you think about this? :)

Cheers
Friedrich