RFC: ideas for a simple OpenDocument API

[Thomas Zander]

On Friday 29 December 2006 20:14, Kevin Krammer wrote:
> However, since I have very little knowledge about ODF implications, it
> could be easier to go for the full API right away. You are certainly a lot
> more qualified to estimate the complexities of each approach, so if your
> opinion is that allowing limitations does not result in benefits for the
> design or implementation, it might be worth waiting for some different
> group to come up with "the real thing" and implement convenience on top of
> it.

I'd say that David Faure is certainly the man with the most ODF experience, 
but I can wager a guesstimate.
ODF has a nice structure of high level objects like pages and paragraphs. With 
redirects to styles for almost all objects.
I don't think you can gain a lot by making your API such that it will never be 
able to gain 100% compliance.
Or, the other way around; I think the best approach is to start with just the 
high level objects and some properties and gradually add more properties when 
time goes by.

> > There are two parts to this;
> > the first is to provide an API to simply get the text and get (some)
> > markup. The second is to provide a way to convert from one document
> > format to another. KOffice already has the second in a large part in its
> > filters technology. There will be lots of interrest in the first, if only
> > someone would start writing it :)
>
> Can you give me some pointers, e.g. SVN directories, API docs links?

http://www.koffice.org/developer/apidocs/
there are 4 KoFilter* classes of interrest there. (all in libs/kofficecore)

There has been some work to create a builder pattern for the conversion 
filters and effectively create a kword-API (for the old fileformat). Can't 
find it right now, and I'm not sure how usefull it is for you :)

For clarity;
all of the KOffice applications tend to load the XML directly from the qdom 
(or its replacement KoXMLReader) into the applications internal 
datastructures. So this framework will probably not be used there.
It is very usefull to have a full ODF API for file-filters for koffice (a.o.).

Cheers!
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061230/99e47951/attachment.sig>