I am just giving a few ideas, just in case that the change of the filter
interface would not accepted by the KOffice core developers.
On Wednesday, 29. August 2001 18:22, Frank Dekervel wrote:
> Hello,
>
> while trying to implement my idea of yesterday i faced some problems:
> 1 the filter API is not totally suited for the job. It requires a temporary
> input file, and an output file (i'd like to pass the data on via a
> QByteArray directly from the filter).
>
> 2 Also, i can't 'force' a mime type ( in the 'import' method of
> koFilterManager i can't pass a 'source' mime type, only a destination
> mime type.) i think i will be able to get around this by using my own
> object instead of koFilterManager. This will result in a lot
> code duplication (since the 'filter' method has several variants).
> can i assume a filter always supports the 'simple' method ? (file in,
> file out, no QDomDocument or KoDocument). Note i won't need all the filters
> (probably only the rtf,csv and html input filters, because the clipboard
> content will never be application/x-word97 or so)
1. & 2. : You can save your QByteArray into a KTempFile with a forced
extension, like for an RTF file:
KTempFile temp (QString::null, ".rtf")
Note for HTML import: HTML import is not supposed to work (see:
http://www.koffice.org/filters/status.phtml .) It will only work the day I
(or someone else) achieve to intergate khtml in it or to use libxml2 with it
or to finish the parser I have writen (it can only XHTML and well-formed
HTML.)
>
> 3 all the current filters use a tar output file, generated by a koStore.
> the application/x-kword-selection and other koffice clipboard formats are
> plaintext. (but, for kword, are just a