On Sunday, October 21, 2012 06:56:49 Thorsten Zachmann wrote: > Hello, > > > Note: this is a problem for some Karbon filters, since they used > > KarbonPart to access shapes for shape painting. We can modify > > KoDocument::paintContent(painter, rect) to do that instead. > > it is not for painting but for creating the structure to read so it is not > easily possible to change these filters as they depend on karbon and can't > be used by e.g. flow.
Yes, it's not for painting. But the fact that the filter uses parts of Karbon to store internal structures before writing new data out shouldn't make it impossible to use by Flow. There are actually three problems here: 1. What Yue points out: That the filters are application specific rather than a generic converter between two formats. 2. That the filter uses Karbon internals in a way that it cannot be used by Flow. This should be more a link issue than anything else, or am I wrong? 3. That the Karbon filter uses KarbonPart instead of the document since the KPart is actually a UI component. This may be the problem that leads to 2 as well so they are perhaps the same. As a side note, I think that Mek once mentioned that the XLS import filter for Sheets uses the Sheets document and then hands the document directly to the Sheets application without creating an intermediate ODS file. If the filter is used in calligraconverter and actually needs to create an ODS then the standard saveOdf() code of the document is used. If I understood that correctly then it seems to be the most efficient way, and the way that the Karbon filters should also use. > Thorsten > _______________________________________________ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
