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

List:       koffice
Subject:    Re: KTar+first draft
From:       David Faure <faure () kde ! org>
Date:       1999-09-08 21:52:03
[Download RAW message or body]

Thanks for sending me the files.
Before I start coding anything (and why MICO is compiling :))
I'd like to make sure about some points :

You suggested a layout like :

lab-report (dir) +- lab-report.kwd (gzipped file)
                 |
                 |- part0.ksp (gzipped file)
                 |- part1.ksp (gzipped file)
                 |- part2.kdg (gzipped file)
                 |- ...
                 |- part8.kdg (gzipped file)
                 |
                 |- KFormula(DIR) +- part9.kfa(FILE)
                 |
                 |- Pictures(DIR) +- picture0.jpg(FILE)
                 |                |- picture1.png(FILE)
                 |                 \ picture2.wmf(FILE)
                 |
                  \ summary.ko(FILE)

0) Why gzip files separately inside a tar.gz file ? 
Torben's KTar handles tgz files, and I would prefer a tar.gz than separately
gzipped files in a tar archive. Especially when manually looking into it.

1) File for embedded parts are in the layout above XML files, right ?  =>
1a) General question : it's not possible to embed a part inside an embedded part,
is it ? If it is (or should be) then we need to make the .ksp, .kdg, ... files
above tar.gz files as well (recursive tar.gz ! Fun to handle !). Don't know, can't
test anything right now... Any expert for that question ?

If not, it makes things simpler :) And we can s/gzipped file/XML file/ above.
And even name all XML files ".xml", otherwise when you see something.ksp you don't
know whether it's a full kspread file (a tar.gz) or a XML for an embedded part
(which you extracted from a tar.gz, for instance).

1b) But... even in that case, they can contain pictures ! So we have to have one dir
per embedded part, finally ! (Or nested tar.gz, depending on 1a)

2) About the format of the summary.ko file : having to parse yet-another file
format doesn't sound good to me. What about making it XML as well ?
Hmmm... Finally doesn't it make more sense to include this kind of info INSIDE
the .kwd file ? This allows one to embed somebody else's document, keeping the
author name in the embedded document...

3) What's the toplevel dir useful for ? For people using tar xzf on it ? Hmm...
No opinion in fact.

Conclusion : my proposal would be (assuming answer to 1a is no)

lab-report.kwd is a tar.gz file containing
(with or without a topleve dir)

/- lab-report.xml (KWord XML) References all dirs below, contains author info + summary.
|
|- part0(DIR)
|   |- part0.xml (KSpread XML. KWord knows it's kspread since the mimetype is
|                 referenced from the main XML file - like it is right now)
|- part1(DIR)
|   |- part1.xml (KDiagramm XML) - contains author as well, might be someone else
|
|- part2(DIR)
|   |- part2.xml (KPresenter XML)
    |- Pictures(DIR)
       |- picture0.jpg
       |- picture1.bmp
|- ...
|
|- KFormula(DIR) +- formula0.kfa     <--- this will disappear if we move to an
|                                               openparts kformula
|
\- Pictures(DIR) +- picture0.jpg
                 |- picture1.png
                  \ picture2.wmf

Names can't be unique, since you don't know how embedded parts name their files.
Here the toplevel and parts2 have a picture0.jpg, but it might be a different file.

Hmm on second thought (actually fifth thought ;) It seems silly to have one file per dir
(if no pictures). We might do instead

lab-report.xml
part0.xml
part1.xml
part2.xml
part2_pictures/
part2_pictures/picture0.jpg
part2_pictures/picture1.bmp
pictures/
pictures/picture0.jpg
...

What do you think ?

-- 
David FAURE
david.faure@cramer.co.uk, david@mandrakesoft.com, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

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

Configure | About | News | Add a list | Sponsored by KoreLogic