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 :)
> 
> 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).

Hmn, I'm not going to use KTarFile directly because I _want_ the
compression. I was talking about storing raw (uncompressed) binary files
in the store. Of course the compression will increase load/save
times...but I don't think this will be very dramatically.

 
> > > 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.

QDom does not seem to be slow for me and it is so much easier to use
than koml.

> 
> > > Just think of a 30MB TIFF loaded from disk, converted to
> > > a temporary KIS image which is saved in a tmp dir and then opened by
> > > KImageShop. What I want to say is that it might be better (faster! :-)
> > > for KImageShop to import foreign file formats directly. On the other
> > > hand a direct-loading filter framework for KIS would of course be
> > > incompatible with the KOffice filter framework, KIS filters would have
> > > to know about KIS internal data structures and link to libkiscore.
> > > Opinions, suggestions?
> >
> >
> > I can think of a very nasty hack to get both, but I'm not sure if that
> > will work so please don't beat me for that foolish idea:
> >
> > Let's assume you use the "normal" KOffice filter interface and optimize
> > by:
> > - allocating a huge chunk of memory (that your KIS image data fits into
> >   that chunk)
> > - converting the file to the KIS format
> > - creating a file which contains some XML (the additional information
> >   and ... yes ... the address of that chunk of memory  >:->>> )
> >
> > 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 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.

Thats exaclty what I need! :-)

-- 
Matthias Elter
elter@kde.org / m_elter@t-online.de

ERROR: Windows has detected that you have moved your mouse.
Please reboot this machine for changes to take effect.