[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    RFC: Optimizing the Filter API
From:       Werner Trobin <wtrobin () carinthia ! com>
Date:       2000-02-24 21:05:43
[Download RAW message or body]

Hi!

As Matthias Elter asked for a filter which is efficient enough
to handle large amounts of data (TIFF images and so on) I
thought about changing the API and streamlining the process of
converting.

Therefore I suggest the following changes:

1) Change the KoFilter class (and due to that all the filters)
   to write (file import) or read (file export) a QDomDocument
   (and not a file as it is now). This QDomDocument is passed
   to the filter in the filter() Method. This is no problem
   since all (non trivial) filters but one (KWord's HTML filter)
   write/read QDomDocuments. For the import filters which use plain
   QStrings I suggest using the setContent() method of
   QDomDocument. This is a small performance hit for that filter
   (KWord HTML filter), but it should increase the general
   performance. Export filters can also easily be rewritten that
   we can use QDomDocument from now on.

2) We have to add a pointer-to-QDomDocument-paramenter with 0L
   as default value to KoFilterManager::import() and
   KoFilterManager::prepareExport(). This QDomDocument is the
   one which is passed on to the filter in case it is available.
   The filter writes/reads this file and we don't have to write
   it to a file/read it from a file.
   It there is no QDomDocument (e.g. KWord will surely not use
   QDom in the next time), KoFilterManager creates its own
   QDomDocument and passes that one to the filters. In this case
   it converts the QDomDocument to a file after filtering. This
   solution guarantees compatibility with the KOML-using-stuff.

3) We have to add a method to KoDocument which provides such a
   empty QDomDocument for loading/saving. The default
   implementation returns 0L (i.e. old technology) and if you
   want to use a streamlined filter you have to reimplement that
   method.
   Another possibility would be to do it the other way (i.e. the
   default impl. returns a QDomDocument), but I'm not sure about
   that.


I think this is not the silver bullet(tm), but as some parts are
using the KOML library and some are using QDom we have to support
both possibilities...

Please tell me what you think of it - I'll implement it ASAP :)

Werner

[prev in list] [next in list] [prev in thread] [next in thread]