The KDE Project today announced the immediate availability of
KOffice 1.2. David Faure, KOffice
release coordinator and developer, noted that the release features "an
incredible number of improvements". What with a truly great
new (English-only) thesaurus, enhanced scriptability of suite components,
WYSIWYG on-screen display, bi-di text, KWord mail-merge and footnotes, and
KSpread database connectivity, enhanced printing and new sorting functionality,
who's to argue? And let's not overlook the constant improvements in the
filters, though the HTML import took a step back to take full advantage of
KHTML's powerful HTML parsing in the next release. Karbon14, the extremely
promising vector-graphics program (with SVG support!), is not officially
in this release but many of the packagers have packaged it as well.
'Nuff said, read the announcement or head straight to the servers and check it out yourself.
KDE Ships KOffice 1.2, an Integrated Office Suite for Linux/Unix
Dot Categories:
Comments
Talk about the day for killer apps! A brand spanking new KOffice. Wowsa. :-)
Especially if you think about the very small number of developers working on the KOffice application.
If you think about this, the number of improvements is just amazing.
Thanks to all of the developers, translators and documentation writers!
Excellent work!
Wish there were more developers for KOffice...
(Sorry, my knowledge about c++ is limited to the knowledge how to spell "c++")
The best way to learn something is to actually do it. :)
Start small and keep growing.
Bye
Lenny
http://lists.kde.org/?l=koffice&m=103165350323482&w=2
"David Faure and I are developing a replacement of the current MS Word filter in KOffice. The project's name is wv2 (the 2nd version of the word-view library) and consists of two parts: a document reader library, which handles the gory parsing of the MS Word documents and feeds a so-called consumer with
low-level library in other projects, too."
"Currently the filter is able to import section, paragraph and character properties, tabs, lists, and several other properties from Word 97 and Word 2000 documents (I didn't test Word XP, but it should also work). I put a screenshot showing some of those features here http://www.sbox.tugraz.at/home/t/trobin/wv2_1.png and here http://www.sbox.tugraz.at/home/t/trobin/wv2_2.png."
"It's planned to support Word 6 and Word 95 in the near future. I also have some documentation about older formats (Word 2, 3, 4, 5), but I consider support for other features like tables or embedded images more important."
"We think the filter has reached a stage where curious developers and users might want to give it a try. This would help us to test the filter on real world documents, not just on our limited set of test documents."
Any news of an export filter for MS Word??
Sounds promising - but - is it only for import?
If so - are you at least designing wv2 with export capabilities
in mind?
Great work on KOffice 1.2, BTW : )
Yes, it's only for import right now. We plan to add support for export too, but there's no point in starting to write an export filter if we still don't understand the file format.
First we would like to get a better overview to avoid writing three export filters, throwing away the first and second iteration because the design isn't flexible enough.
Please be patient :-)
Any chance of getting together with Openoffice and
1. Using the code from their excellent MS filter capabilities - in and out
2. Producing an open standard for documents so that users of KOffice / Openoffice / anyotheroffice can exchange docs freely
?
Not a KOffice developer, but I follow the lists, so I might be able to help here.
1. The OpenOffice.org filters, the way I understand it, convert the word documents directly to their own internal structures so the code cannot just be reused. It can be used to figure out some obfuscated features of the file formats, and I believe the KOffice people have been doing this. The KOffice filter infrastructure is very capable, the only thing missing is a lot of reverse-engineering that's gone into OOo. Unfortunately, the code there is specific to OpenOffice.org.
2. Work has been going on in that direction (for example, the KOffice 1.2 uses zip instead of gzip for compression), albeit slowly. On the other hand, there is an OpenOffice/StarOffice filter in the works for KWord.
Re .2
That wasn't what he was getting at. If all the non-MS Office packages use the same native file formats, so that for example docs generated in KOffice are the same as docs generated by OpenOffice, or AppleWorks (and all involved actively work to maintain compatability) then there is a real chance that the world can break the strangle hold MS has on desktop office software. As a side effect, this will also undermine their desktop monopoly.
This is the only way out of the dilema we find ourselves in today. Trying to work around it with filters just won't cut the mustard. Until we take this step, nothing will change.
I think you misunderstood me, we are in agreement. I meant to say that it seems to me that the KOffice team are considering the switch to a common file format (see Holger Schroeder's post elsewhere in this discussion). Following the discussion with other open office suites, they changed the file format to a zip file instead of the gzip used so far -- same as OpenOffice.org uses. Other changes are coming, but will take more time. In the meantime, we will have filters for interoperability.
that isnt right dont listen to him
Export? Why? that's only promoting M$ Office use. We should export only to free as in freedom formats.
We should export to useful (as in useful) formats.. and as convulted as the M$ formats are... they are certainly useful.
this is only for koffice-HEAD, that will become koffice1.3!
the filter in koffice 1.2 is the good old one, that works well enough for me...
i would be more interested by a powerpoint import, but i'm already very happy of all of this :O)
Exactly, Powerpoint and possibility to import the pictures embedded in Word documents, too.
> "David Faure and I are developing a replacement of the current MS Word"
Sounds great to me. :-)
IMHO, perfect Open Office filters would be a huge boost for KOffice and since they are properly documented, they shouldn't be very difficult. If KOffice has good support for the Open Office formats it will allow KOffice to gain from all the work of the Open Office filters.
Abiword and gnumeric filters are also import as are filters for Star office. Open source office packages should lead the way in interoperability of files.
David
I think even more important that having filters, would be to create an open standard format that all of the open source programs use. This would create much bigger impact than some filters could ever hope of doing.
Then I would humbly suggest that OpenOffice serve as those standards. They are very well documented and seem entirely adequate for the job. I know they use XML/XSL and are zipped for efficiency. So, if any KOffice developers are reading this, how about adopting the OpenOffice formats as the KOffice standard?
Definitely yes!
Guess why we switched to ZIP?
Now, switching the file format is a lot of work - you need to know both file formats,
to change the internals of the loading/saving in the application, but also to port all
the import/export filters!
This isn't a one-man one-day job (not even one-week). So: any help would be really appreciated.
So yes, I like the idea, but that's not enough.
The first step is to compare both file formats and check if everything we support,
is supported by the OO format. I know that Holger started doing so, but I don't know
what the current status is.
well, the actual status is i am writing my diploma thesis...
i will sei if i can find some time in between, but at the moment, it has to have a little lower priority...
(the only "thing", that is missing, is a programming dude, who does the work, i have an xslt filter working, which takes a kword file and transforms it into an openwriter file, that means, get the xml files out of the kword zip, transform them and put the resulting xml files into another zip file, which can be read by openoffice.
the things i have working:
letters ( ;-) ), placing textboxes on the pages, colored text, text size, text attributes (as bold, underlined,...), images (sort of)
what doesn´t work yet:
tables, embedding other objects, probably more.
so i came to the conclusion, that the openoffice xml format is almost almost fully capable of holding all the stuff we have in the actual kword xml format, and a lot more.
the task to do is:
for the loadXML() and saveXML() methods in kword, write the corresponding loadOOXML() and saveOOXML() methods, which can read/write valid openoffice xml.
we also don´t need to fiddle around in all the filters, i would vote for having the koffice- and the openoffice- load/saveXML in the source for a longer time and don´t force somebody to change his filter to the new format, as the old one works well.
for some screenshots go to http://holgis.net/ . there is a picture from the kword window, which i saved a .kwd file from, and on the other picture, there is openwriter with the resulting document opened.
(in download, there are several versions of the xslt filter, and an openoffice document, which contains a script. with this script, one can basically ude openoffice as a ms office <-> openoffice filter, no need for the user to do anything to open openoffice or so, it can all be done from the command line.
so when we teach koffice the openoffice file format (should work for kspread and kpresenter as well...), we get the openoffice filters for free.
well, now i hope, that i have convinced someone, that this is the way to go, and, that someone wants to help with this ;-)
the programming itself is not that hard, it is mainly saving the xml entities
in another order, to match the openoffice dtd, instead of the kword one.
no need to learn gui programming, no need to learn all the rest of koffice,
for the people interested, look at the loadXML and saveXML methods in the file
kwdoc.cc in the kword directory in the koffice sources.
i´d be glad to help anybody, who likes to start with this, ohterwise you have to wait a little bit longer, til i find time for it ;-)
thanks, Holger
Great news Holger! Thanks for all your work.
If I can find some time, I'll have a look at the LoadXML and SaveXML methods. If all that is required is some archive methods which will save to the OO DtD then this should really be a piece of cake.
Thanks again!
So, basically, the filtering stuffs that you refer to is unzip the existing openOffice file and do some manipulation on the files and zip it back to OpenOffice file format, is it?
As for me, im currently analysing how to solve a problem in which for my application, it needs some extra information for any .sxw file. After studying some articles online, I thought of to add few xml files to the unzipped OpenOffice file and zip it back to OpenOffice file once it is done. But I'm not sure if this is the best solution
I also thought of maybe i can look into OpenOffice filters and try to write my own filter, anyway, i think it is going to involve c++ stuffs and i will have to look into the existing OpenOffice structure.I feel that it is going to take much longer time to complete the job yet I dunno if this is the right direction to explore.
So, may i know your opinions and advice towards that?
Thanks alot, and hope to hearing from you as soon.
We already thought about this.
But in KSpread we/I decided, that we/I finish the OpenCalc filters first (import is nearly done but not in CVS yet) and if they work perfectly we can think about it again.
KSpread 1.3 is going to have much improved filter.
It is obvious that most of the people using (or that will use) Linux as a desktop operating system are using (or will use) OO/StarO. If Kword and kspread are using the same file format natively, then it gives them a big chance to be adopted as they:
- are Less bloated
- integrate perfectly in KDE
- make it possible to work on a Linux desktop with all the applications using just one toolkit
I think the idea of using their format sounds dangerous at best.
First of all, they might change it in coming versions, which will bring back the compatibility problem. Second, who knows if the format will support the features the developers wish to add to koffice. Third, will koffice ever get to support the entire format?
Of the 3, i think 1 and 3 are the biggest problems. Unless koffice can really handle the entire format, you dont have true compatibility anyway in which case i think the point is gone.
I think chosing a file format that others control is quite brave, and deffinately something i would not personally do. One thing is export/import filters getting out of sync, but actually basing your internal format on what another office suite can do, well, sounds like a bad idea to me.
But of course, others may see it differently.
As a sidenote, im already worried about switching to zip, as IIRC the zip format is not entirely open.
Don't worry. The discussion about the standart office file format choose the OO file format as the standart, with some additions. The base of the standart format will be the OO format and they know it. There won't be a great change in this format, so no incompatibilities.
The koffice will not "base the internal format on what another office suite can do", will base the internal format on what the standart format will support.
The discussion for choosing the zip format was long. The zip format has many advantages over the other formats.
For more information, read the maillist archive for the open standart office file format: http://xml.openoffice.org/standardisation/
look at http://www.pkware.com/support/appnote.html . there is a description of the zip file format. pkware only claims copyright of the file describing the format, nothing more. so we simply wrote a kioslave, which understands the described format, and we were done. i don't see why this should worry anybody.
you get faster saving and loading times by this switch to zip, and you don't eat up as much memory as before, as you don't have to hold the whole archive uncompressed.
what's wrong with teaching the open source office applications a common file format? i think this is the way to go. if you look at the openoffice xml document type description, it is already quite complete, so don't worry about not enough support for what we want to save. it should be quite easy to display all text from an oo document, it can come to incompatibilities, when the text has some special attributes like underlined three times or whatever, but then we can simply underline it in kword and then put "three times underlined" on our todo list.
and even if we see, that we have to add something to oo's dtd, we can derive our owd dtd from theirs, include what we need and work together with the oo people to include this into their oo dtd.
this is still a far way to go, but imagine you could forget about file format incompatibilities in some time, you simply exchange office documents, which are not saved with ms programs. think of postscript, when you have ghostscript, you are able to view it. this compatibility should be our goal.
so you can forget about microsoft trying to force everybody to "upgrade" to the actual version of their office suite, because the oo file format is forward compatible. this means, they won't change their file format in some random way, they will only add some xml attributes or so, and the old programs will simply read over them and don't take care of what they don't understand.
no need to upgrade, if you don't want...
I think SUN is already working on this. They are busy working on Standard format derived from Open Office format, they intend to submit it to a standard body, maybe OASIS. He said that they will make an annoucement as soon as they are ready. This is part of SUN new initiative on the Desktop.
Here is how I see the things, and I imagine some companies see too:
If open source can't agree in a standard, how could community ask for it from some companies?
Yes, I know, this sounds as trolling and bad, but maybe it's true. Let's think, we complain about microsoft not opening their file systems, but why they don't? Because by using a own and proprietary file format they have advantave over competition.
Well, if competition is fragmented in some file-formats, how would they expect m$ changes to open, or people adopt their formats if there are many and they don't work with all applications?
I think the big battle for winning desktop are file formats, not the interface, not the setup, but if people see they can handle their data on any different system, they will be really free to change for anything they want.
So, in resume, good open formats is the key for freedom of choice.
Reguards people, and keep the good work, I have faith in understanding and collaboration! :)
I fully agree with you, we should think 'format-based' instead of 'aplication-based'. Good, true open, and well documented formats are the real keys for the ultimate freedom. Ofcourse both open-source people and commercial softwaredeveloppers should be able to use them.
I have been in the process of migrating my system (and mind) out of the M$ world for all my business needs. I, unfortunately, have a lot of work, recieved and needs to be sent, in M$ formats. I tended towards OpenOffice, since it provides the ability to read/make the M$ formats. I like the work done by the koffice team, but not having the ability to either read/make OO (at least) or M$ formats locks me into koffice like a bad date. All this said, the potholes are many, but i agree a combined/standard file format should(MUST) be found (and it is possible); the compressed XML is the best direction, and it can facilitate any need. KO and OO are both Open, thus some discussion and handshaking should be able to hash out combining the DTD for all common elements; any diveregence for each, KO or OO, special features are incorportated into the DTD until which time the other App picks up the feature. The battle over File format is a disturbing one (after all its my @$#$@ data), so please find good common ground. HRC:)~
Would be cool if KOffice 1.2 could make it into the upcoming Mandrake 0.9
It's contained in Mandrake 9.0 RC2.
That´s the KOffice RC...
Mandrake 9.0 will have koffice-1.2-final.
thanks David!
Well here we go again. No RedHat binaries!
I sent a question about this at RedHat web pages, let's see if they bother to answer. Seems like the only options I have would be a) compiling from sources or b) changing distribution...
Is someone kind person making those unofficial rpm's this time?
Best Regards,
Eleknader
Then change distribution. SuSE 8.0 with apt-rpm is a real killer.
Yeah, get away from RedHat. They choosed a very bad path to go. It is not normal that only Bero is packaging KDE stuff. This is a large project, they need much more people to help him, as he cannot do all this by himself.
But RedHat is a KDE bashing expert, and a Linux-will-never-make-it-to-the-desktop strong advocate, which can also be translated as Microsoft-please-don-t-change-too-much-windows-or-we-will-die, but they don't seem to realize it. If OpenSource/FreeSoftware succeed durably, it'l be in spite of RedHat, not because of them. They had their role in the past, a good and necessary role, but now they're to be put back on the dusty shelves of history.
Go for Mandrake or Debian or Gentoo or SuSE or Connectiva. A lot of good distros out here, whether you are beginner or not, installing on a server or on a desktop, GNU/GPL fanatic or not, etc.
RedHat has lost the very few credibility they had in the KDE and Linux-Desktop community. Let them lay down and die. I still don't swallow what they did with KDE 3(.0.x), it's unprofessionnal, and send only one message saying how little they value all the tremendous work done by the KDE team. It's a polite "fuck off", nothing else.
I know I'm feeding a troll here, and maybe trolling myself, but here it goes:
I agree with you that if Red Hat is going to ship and modify KDE, they should have more KDE developers on staff. But calling them a "Linux-will-never-make-it-to-the-desktop" advocate is no longer appropriate, since their next release is aimed squarely at the corporate desktop. Yes, in the past they weren't interested in the desktop, but now they are doing a fair bit of work on that front. Also, I really don't think Red Hat is going to die any time soon just because they don't support one (albeight large) project very well. As for Red Hat making themes to unify KDE and GNOME, I think it is a good idea.
If KDE developers don't like that the QT/GTK themes in Red Hat 'null' make everything look GTK, then why doesn't someone develop a GTK theme that makes GNOME apps look like they're using default KDE 3.0/3.1 widgets. Ideally, a system where KDE apps look like GTK while being run in GNOME, and GNOME apps looking like QT/KDE apps while running in KDE would be ideal. Although I haven't seen Red Hat 'null' for myself, it appears from discussion that they are doing one side of this equation for us (among other things that people, maybe rightly, are not happy with). Since a consistant look and feel has always been a feature wanted by some desktop users of KDE and GNOME, I see nothing wrong with them trying for it, especially since KDE and GNOME themselves have not implemented it themselves yet. If KDE and GNOME already has a system set up where consistant look and feel could be achieved across both desktops for those who want it, then Red Hat probably would've gladly used the existing code instead of writing it themselves.
So that's why they remove the "About KDE" dialog? Is that what you call a good idea?
They hide the KDE apps and if a user accidently finds one he shouldn't know that it belongs to KDE just in case they like it.
And if they start KDE they'll find just a misconfigured something - so RedHat hopes they say, oh, I don't want that, give me Gnome instead.
Don't buy RedHats distri. There are so many good distributions outside...
You are not being objective.
What RedHat did is just great. Integration and consistency will be greatly appreciated by most of the people (obviously not by people in GNOME and KDE internet forums).
If you didn't like that they removed the "About KDE" dialog, just write them a polite e-mail inviting them not to hide your work. I think you are in your right to do so.
In any case GPL allows 3rd party developers/companies to touch your software. You knew it before starting KDE. You can move to anothre license system.
My 2 cts.
This whole "GPL permits it, so you can't complain about changes" thing makes absolutely no sense. It's like saying that believing in free speech means you can't criticize anyone for saying something. There is a very significant difference between giving someone freedom, and approving of what they do with it.
I agree
btw.:
''What RedHat did is just great. Integration and consistency will be greatly appreciated by most of the people.''
Well, you are right.
What means integration of gnome apps into a KDE desktop ?
Simple: Put all gnome apps aside the KDE native apps in the menu.
You can name the entries like 'KMail (e-mail client)'
and 'Evolution (PIM-Application)'. Be sure the user will recognize a
native KDE-app (and if it's simply by the K in it's name).
Get the mimetypes correct. Give the user the freedom to open a
xls-file with KSpread or Gnumeric (KDE supports this!)
You can do this the other way round with Gnome, of course.
An it's really a fine idea to build a general look-n-feel theme for
KDE/qt and gtk/Gnome apps.
But: _Never_ remove an about box. Respect the authors of both desktop
environments. Both teams are proud of their work and I'm sure the gnome
team does not need to get such a support from RH.
You can't tell me an about box is disturbing the user.
For competition a KDE-desktop should be a real KDE-desktop with all
nifty features. KDE's strength is based on the idea of a bunch of
apps playing together very well (and it works!).
This does _not_ imply you'd have to hide all fine gtk-apps from the user!!
> So that's why they remove the "About KDE" dialog?
Inaccurate fud.
FYI, the patch to remove the "About KDE" dialog was removed from RedHat's rpms a long time ago. If you're going to complain about redhat, at least be accurate.
...And replaced by an equivalent one done with action restrictions