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

List:       koffice
Subject:    Re: kimageshop native file format and koffice filter framework
From:       Werner Trobin <wtrobin () carinthia ! com>
Date:       2000-02-23 4:55:01
[Download RAW message or body]

David Faure wrote:
> 
> On Tue, Feb 22, 2000 at 08:40:10PM +0100, Werner Trobin wrote:
> > Matthias Elter wrote:
> > >
> > > Hi
> > >
> > > 1) I'm currently implementing a native KImageShop file format using
> > > KoStore and QDom. I'm basically saving image/layer/channel attributes in
> > > the XML file (see kimageshop.dtd) and the actual image data in binary
> > > files, all stored using KoTarStore. This gives me
> > > LayerCount*ChannelCount binaries. All in all this is a easy to handle
> > > and more important easy to write import filters for file format. Any
> > > suggestions regarding the file format?
> >
> > I don't know if KTar is able to handle that, but by default it compresses
> > the binary data (=images). If I save a png image I loose some time because
> > it is compressed already. Am right? Is the "performance hit" big enough to
> > optimize for that case? David?
> 
> I have no idea about performance losses because of the compression.
> gzopen/gzwrite is ... transparent :)

Ahhh... I don't know that KTar stuff.

> KTar supports non-compressed tar files, in fact. But it's KoStore which
> uses KTarGz, always. So there is a simple solution : use KTarFile directly.
> 
> KoStore does nothing, it's just the abstraction layer that allowed
> to switch between the two file formats. Well, it does one thing: the conversion
> between the old naming (tar:/0/1) into the one used in tar files
> (can't remember. something like part0/part1/maindoc.xml. See docu :)
> 
> If KImageShop respects this naming, it should all be fine.
> 
> (Note that gzread handles uncompressed data, so for loading there is
> no problem, even in another ko app).
> 
> > > 2) I had a deeper look into the KOffice filter framework recently. Great
> > > work, Werner!
> >
> > Thank you! Now we only need some filters :)
> >
> > > While I like the current implementaion I'm a bit concerned
> > > wether it's going to work for KImageShop. The problem is, while KWord
> > > and KSpread documents are (relatively) small text files and (relatively
> > > ;-) fast filtered with the current approach, importing a large TIFF
> > > image into KImageShop would be quite slow because of the indirect nature
> > > of the filters.
> >
> > BTW: Last time I checked QDom was dog-slow. Any news on that, David?
> 
> ... when used in the CSV filter it is dog slow. But I haven't
> had the time to investigate more. See my comments in the xmltree file
> (around the XXXXXX you put there to measure time). I think
> is has something to do with the UTF 8 encoding - looks like
> a bug in Qt but I'm not sure.

Yes, I've seen that. I thought the Trolls fixed that for beta1.

[snip]
> > KIS opens that temporary file and sets a pointer to that address :-P
> > Now you have got the data of your image. All the additional data is
> > stored in the remaining XML of the file...
> 
> This is getting very very hacky...
> Gosh, it's all in the same process. Can't we design something that
> gives the QDomDocument pointer directly, for those who want it ?

I'll look into it tomorrow. IIRC the API has to be changed :)

> I understand we usually use a temp file in order to let the app
> parse it the usual way - important for those apps that use koml
> instead of QDom.
> But for a brand new app which uses QDom natively, it should really
> get hold of the document created by the filter directly.
> 
> --
> David FAURE
> david@mandrakesoft.com, faure@kde.org
> http://home.clara.net/faure/
> KDE, Making The Future of Computing Available Today

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