Submitted by Last friday, the KOffice team started their ODF meeting in Berlin. Many people showed up at the KDAB office, and spend their time discussing, designing, and hacking on KOffice. They came up with some new things.
Last friday, the KOffice team started their ODF meeting in Berlin. Many people showed up at the KDAB office, and spend their time discussing, designing, and hacking on KOffice. They came up with some new things.
I especially like the idea to get ODF libs available for developers outside the KOffice project.
This is extremely usefull for applications that work with tabular data, e.g. all applications which nowadays have Import/Export from/to CSV (comma separated value files).
CSV files are a mess: one needs to know (through user input or preprocssing/autodetection) which character is used as the delimiter, has to be carefull about quotation or escaping of the delimiter, there is no hint on the content encoding, …
The same content as an ODF table would be trivially to process, one could even transport cell types, e.g. number, date, currency, etc.
If I remember correctly there is another project (possibly an Apache one?) which also aims to create an “ODF toolkit”.
“I especially like the idea to get ODF libs available for developers outside the KOffice project.”
The idea of using a library instead of re-inventing a ODF file creator is a great idea. It could be used to create documents which are prepared to get edited in KOffice, e. g. you have client data from one of your patients and want to create a medical report, so the basic data (name, date of birth, insurance number, registration code, diagnosis, test results) is already in the document (which already contains your company head, address, phone etc., along with the date) when KOffice starts for you to enter the report text.
While ODF can be processed everywhere, you can even not use KOffice and use OpenOffice for editing instead, if you want.
“CSV files are a mess: one needs to know (through user input or preprocssing/autodetection) which character is used as the delimiter, has to be carefull about quotation or escaping of the delimiter, there is no hint on the content encoding, …”
You’re right. While this listing solution is okay for small amounts of data, it can get extremely complicated for more data, especially if data fields are “encapsulated”, meaning they contain another dataset, such as “X220180:2007-05-01,2007-05-10,2007-05-12:F32.1”.
“The same content as an ODF table would be trivially to process, one could even transport cell types, e.g. number, date, currency, etc.”
The “decompilation” of ODF is relatively easy, so documents created in ODF format (and following a certain specification) could be re-imported to another application.
Exactly!
And even more complex processing “pipelines”, i.e. one application generates an ODF file with measurement data, another one takes this as its input and adds statistical analysis, and so on.
I think Rob Weir (IBM) has a presentation about “20 non-office things one can do with ODF” (not the exact title, it’s similar though)
Also makes it a good candidate for a common tranport format in Copy&Paste operations.
I hope that they make sure to involve others outside of KDE on this, such as Apache, FreeStandards.org, GNOME, Apple, Corel, and OpenOffice. It would be useful to have a KDElib for this but it would be even more useful to have a more generic lib or at least standard for this. Perhaps the work KDE does could later be more generalized but I think they need to include others in these ideas right now. I don’t want to see ODF become the next POSIX and divide up into mostly but not fully compatible standards.
Also I know that the ODF ISO standard is much shorter than the MS OOXML ISO draft is so does that mean that all these additions will increase the length of the ODF standard? I’ve heard some people on the net make comments alleging that the current ODF standard is very incomplete and I hope that KOffice, OpenOffice, and others work to rectify this. I may be completely off my rocker here so please correct me if I am.
Also I’m glad to see that KOffice is advancing and I look forward to KOffice 2.0 in 2008. Also is KOffice planning versions for Windows and Mac OS X at this time?
They work with them because they use ODF. This library is a KDE lib by nature, compare it to Solid and Phonon (resp. hardware and multimedia abstraction). OpenOffice is working on a comparable toolkit, though it’s mostly aimed at server and java-based solutions. But there is no reason why that can’t change in time.
Yes, if they need things in ODF twhich isn’t available yet, they can add it. After all, they already did when ODF was created.
Afaik not very actively, but they will get at that.
iirc, there is work being done about porting the whole of kde over on windows as a alternate desktop.
but its probably a whole different story to attempt something like that on osx.
hell, if they manage to make the background kde libs usable on windows and osx, porting the office should be a lesser problem imo.
the qestion really is about making it modual enough. its not like the koffice only use qt. it also use a host of kde libs to integrate stuff like kparts and all that (iirc).
so one is looking at a partial port of kde if one wants to use koffice on windows or osx. just look at the stuff that needs to be installed under linux to use koffice inside gnome or similar…
Not necessarily.
Windows will be easier GUI-wise, since the concepts of iteraction are quite similar to what KOffice does on Unix/X11, however, below the user interaction level Mac OS X is more similar than Windows (filesystem behaviour, process handling, …), so affectively it might be a comparable effort.
there is work being done about porting the whole of kde over on windows as a alternate desktop.
No, it’s not! The work being done to is to port the libraries and applications to Windows, the desktop is not being ported.
Why should it? Windows and osx for that matter, already have a desktop. The KDE desktop is the added benefit you get when running a *nix platform.
but its probably a whole different story to attempt something like that on osx.
Yes, but it’s much further along than the windows port. And you can already get KOffice binaries. It’s of course just as much in beta as the rest of KDE 4.
http://ranger.users.finkproject.org/kde/index.php/Home
Should be:
http://koffice.kde.org/
instead of:
http://www.koffice.kde.org/