ZDNet has published a review of KOfficeTM.
Titled "KOffice falls short of Microsoft Office standard: Updated Linux
alternative to Office not ready for corporate big leagues", the lengthy
review takes a close and, perhaps surprisingly, fair look at the strengths
and weaknesses of KOffice. While generally lauding KOffice, its design,
stablity and capabilities, the review identifies four factors which, in
the reviewers' opinion, makes KOffice currently unsuitable for corporate
use: (1) shortcomings of the MS Office® import filters; (2) lack
of MS Office export filters; (3) the lack of some KWord features, such as
a thesaurus, automatic spell-checking and (uggghh) grammar checking;
and (4) some missing features in KSpread, some easy to fix (such as
case sensitivity) and some not so easy to fix (such as the ability to
import VBA (Visual Basic for Applications) scripts). All in all,
surprisingly similar to my own
review.
ZDNet: Review of KOffice 1.1
Dot Categories:
Comments
You already have, what you your are asking for :)
There are Python bindings for DCOP in kdebindings module IIRC, so you an use Python to script any KDE app with a DCOP interface, especially apps with such complete interfaces as KOffice apps.
David Faure wrote a reply about this to an email on koffice mailing list.
Subject is Automation of Koffice.
Check the archives to find out more.
Cheers,
Kevin
You already have, what you your are asking for :)
There are Python bindings for DCOP in kdebindings module IIRC, so you an use Python to script any KDE app with a DCOP interface, especially apps with such complete interfaces as KOffice apps.
David Faure wrote a reply about this to an email on koffice mailing list.
Subject is Automation of Koffice.
Check the archives to find out more.
Cheers,
Kevin
As someone who spends his day writing VBA in an all-Microsoft shop, I have to agree. VBA is a punishment after a fun weekend of Perl or Python. Seriously, the LANGUAGE is broken, not just the capabilities. Please KDE-team, don't even try to emulate this crap. Better functionality can be gained from any of the open-source scripting languages out there, and you can even (gasp!) code it with built-in security. But you already know that. Keep up the good work.
I second that. I also have to struggle with VBA all the time at work and it just SUCKS.
A few times a day I shake my head about language inconsistencys and similar.
VBA is not at all an easy to handle language like (as already mentioned) Perl or Python.
Just an example... I wondered a few hours, why
mysub( "arg1", arg2" )
didn't work. It told me crap like "2 arguments expected" or something like that.
Later I found out, that I am not allowed to use brackets when it's a procedure (sub), but I HAVE to use brackets if it's a function. Yeah great...
And they tried to tell me, that would make sense.
> VBA is a punishment after a fun weekend of Perl or Python.
> Seriously, the LANGUAGE is broken, not just the capabilities.
> Please KDE-team, don't even try to emulate this crap.
The problem is a bit more complicated, of course. Large corporations -- the ones most likely to take the initiative of moving to KOffice because the cost savings are so substantial -- likely have a *lot* of documents they regularly use which make use of the VBA technology. Whether this is good or bad is not really the issue, the issue is that their migration costs become quite large if they have to manually rewrite these scripts and retrain their users how to use them.
This of course does not mean that KOffice needs to provide VBA. What it does mean, however, is that the import filters need to be capable of converting VBA scripts to whatever language (Python/Perl/?) KOffice uses for its scripting language. With that goal accomplished, desktop users in corporations and at home can open existing documents and work with them "out of the box".
Maybe theres middle ground... What if the import filter
translates the VBA script to python?
Who said we would ?
I was just referring to the bit of the article that describes KOffice's lack of VBA as a bad thing. Personally I think it is great, considering what an awful language BASIC is (some say learning BASIC first damages your ability to learn decent languages later). I recently learned Python for some maintenance I had to do to some Python CGIs. I like the language a lot, so I am going to read up on the Python bindings to KOffice someone mentioned in this thread.
I don't understand why the KLyX project has been dropped. This was supposed to become a KOffice component at one time. As M. Ettrich once pointed out, the overemphasis on politically correct "GUI-independence" has caused the original LyX project to languish. I really wish KLyX would be started up again. It would complement KWord. And if the unicode extension of TeX/LaTeX (Omega/Lambda) were supported (since Qt3 has better unicode support), KDE could have a killer typesetting application with no competitive product in the traditional office productivity lineup. Imagine typesetting different languages with different direction rules in a single paragraph or sentence. With correct hyphenation, etc! And without becoming a TeXpert. This is an opprtunity to take the lead (in the true M. Ettrich tradition) and not merely imitate M$ or Adobe.
WADR to the LyX developers, forget political correctness. Port LyX to Qt3 and let's move forward!
I know this is slightly off-topic and I personally think it deserves it's own article. I hope that one of the developers can take a few minutes to talk about it. As a scholar (not a programmer) I would be willing to work with a KDE developer to write a university grant proposal to get at least some financial support for such a program. And if Shawn is interested, I'll buy a copy and be it's greatest advertiser!
More on this later.
Samawi
didn't finish filling the email address form...
Yeah, that's what I was thinking while looking at LyX. Even though I know zip about TeX, I was able to make fairly detailed documents in it, and was thinking : "Wow, make this a kpart, and also allow kparts to be embedded into it (perhaps with inserted bitmaps or something like that) and this would be the ultimate office app"
(btw, replying to this and not above post so that you get email notificaton for responses, in case you wanted that)
[slightly OT]
I agree almost completely with you. I still use KLyX for *all* my schoolwork, and I have to say it prints better documents than "equivalent" programs like MS Word and WordPerfect. I don't think, however, that KLyX should be restarted. It does some things very good, but so does the original LyX. And that one is still being developed. Let's not get into a UI-war where everyone writes his own copies of a program, just doing the same work over and over. One could probably add some things as an extension to LyX, but that's entirely different from just implementing the same over and over. What I would like to see (and if possible help, but time is very short these days): Lyx, just like it is now and activily being developed. Then there could be some people writing patches for instance to turn it into a KPart, building further on the LyX-base. That would give a cool application to all Linux-users. Maybe at last the whole codebase could be turned in some sort of backend, with some people writing frontends for it, KDE-based or not.
[/slightly OT]
The upcoming Lyx 1.2 release will be compilable with a QT2 frontend.
Have a look at the lyx-devel mailing list (www.lyx.org) and you'll see that this release is getting very close.
Yes, it's a shame that it's taken so long, due to the GUI-independence thing. Since QT is 'free' for non-commercial use on win32 and linux now, I think that it probably would have been better to go for an all-qt rewrite originally, with the benefit of hindsight, of course.
I recommend anyone who uses KLyx to download the CVS Lyx sources and try out the QT2 version - help the developers iron out the remaining bugs.
I assume they will port it to QT3 pretty soon, so it should fit nicely into the KDE3 architecture, with plugable styles etc.
This would be cool. Every important document I ever made in Linux was using Lyx (many homeworks, my thesis, ...). I don't think I should even consider writing huge, important papers in KWord. I allways loved Lyx and KLyx and it would be great having it again in KDE3!
I just wonder, having LyX working with Qt, then (hopefully) with KPart, do we still need KWord? I think decision for issue like this should be done ASAP.
I agree with you. When Lyx GUI-independent finally is released, I really hope that the KDE team will integrate and make Lyx-KDE an important part of KOffice. LaTeX simply rocks when it comes to writing scientific/technical documents!
I couldnt agree more. KLyX absolutely kicks ass... I dunno what this gui-independence thing is all about but I for one would love to see a KDE (not just bare Qt, I'm talking KPart/KIO/KOtherReallyCoolStuff enabled) based KLyX again. I for one can't imagine what on earth anyone would need KWord for (KParts not playing nice with TeX?)
...regardless, PLEASE take the project up again, whoever maintains it!
True, so true. PLEEEASE integrate LyX into KDE and add a Reference Manager such as Endnote that can directly access library catalogs over the web, e. g. Library of Congress.
Found this article while searching for any more info on getting the qt
frontend to compile on FreeBSD... i found some good tips (URL below),
but it still won't compile for me. I too, would *love* to see LyX slurped
into the KDE... LyX is just so excellent at what it does (even if a little
constraining in some areas -- without resorting to raw LaTeX).
Right now i'd just like to get the thing to compile with qt3, though.
http://www.mail-archive.com/[email protected]/msg47212.html
Import and export of documents in MS formats is a wast of time. Luckily the designers of HTML and HTTP weren't constrained by such silly requirements or the web would not exist. Although this is what many Intranets now do. They simply require the use of IE and Word and all MS equipment. IE embeds a word doc viewer. Users don't even know they're viewing a "Word Document" when they browser the company "knowledge base".
Groups like OpenOffice, AbiWord, Applix, Koffice, Gobe, and the Mozilla group should get together and establish a workable XML based open standard. Maybe if papa Microsoft let's them Corel(WordPerfect) might show up. Don't even invites MS - if they ask nicely to be allowed to attend then maybe .... The compatabilty with MS is a not an idea that will not get ANYONE to switch over in anycase. People do know this don't they?? Perfecting import filters is not the best route to win new users.
The focus should be on the new next generation document formats. Some sort of mostly working "conversion tool" to get the documents *out* of MSWord format might be useful. But demanding perfect import filters is stupid. We all know that what most of these open and commercial applications need is spell checking, hyphenation, thesaurus tools etc. Hopefully Aspell can solve these problems since it can be used by other apps easily and has dictionaries that are easily extendable and cover many languages. And hopefully more of the commercial software producers will be able to find ways to leaverage and cooperate with open source projects.
IMHO grammar checking is a ridiculous and wasteful feature. The advice given by most grammar checkers is absolute crap and I know no one who seriously uses this kind of tool. If this is a really needed feature a separate application project should be started (hopefully very internationalized) and designed like Aspell to be easily embeddable in other projects. It would hopefully focus on Thesaurus and Synonym features ... with only minimal grammar checking. It would be easiest if this app had a good stable XML format to work with and if professional linguists were on board for the effort.
The key is to leaverage the superior format so that the above projects can set the STANDARD and not waste time and resources
* All of these applications (most of which run on Windows too) could read documents produced by any of the others (some such as Abiword couldn't easily rely on embedding a component to read an embedded spread sheet and would have to fall back to something else)
* Any of these applications would produce slick XML docs readable by Mozilla browsers
* Any of these applications would be able to save seamlessly to Zope or Apache web stores.
* The XML standard could be easily extended so that video and sound appear.
* A directory based approach to "compound documents" (a la NeXT's excellent LaTeX editing enviroment) should be developped this would instantly place all free tools ahead of MS-Office.
* Becasue of the format the documents could be indexed and searchable with XML aware DB applications in a trivial way.
Don't waste any more that n the minimum of time trying to be compatible with Microsoft.
In kindergarten I notice that usually if the big kid takes his ball home and won't play with the others the others keep playing. Eventually the big kid comes back - chastened and regretful and asks to play with the group.
Absolutely agree with you.
I can't stand this "Import/Export" issue anymore. Something has to happen.
And I do not care the slightest bit, if Microsoft plays with the group.
If they ask to be outsiders, they SHOULD be outsiders.
You are very right, the kids shouldn't run after Microsoft and ask for it's ball.
:: Groups like OpenOffice, AbiWord, Applix, Koffice, Gobe, and the Mozilla group should get together and establish a workable XML based open standard. Maybe if papa Microsoft let's them Corel(WordPerfect) might show up. Don't even invites MS - if they ask nicely to be allowed to attend then maybe ....
Yeah! And you know what would be cooler? Is if we all got CAKE!!!
Seriously. This is a great idea in an ideal world, but it's not gonna happen. At the very very least because there is too much content wrapped up in Word documents at the moment. There is a great inertia, and if you can't bring your training *or* your content over, switching to a different office suite has no incentive. As it is, the training has to be redone constantly (new versions, new employees), so retraining to KOffice is not a tremendously big deal. After all, KOffice, WordPerfect, MS Word, Abiword - to someone who wants to write pretty text, they are all pretty much the same. Drop down of fonts, and four buttons, one with a bold "B", an italic "I", an underlined "U", and one with a picture of a printer on it. It's amazing how many people don't know how to cut and paste, drag and drop, use undo, or anything like that.
But they use "That file on K:/Betty/" to file for a client who wants to do foo. I've been in an office where they used chinese documents, and nobody spoke chinese - they just printed out the one that corresponded, without knowing what it was, because "that's what you do".
It's much easier for single users and extremely large corporations (who already deal with structured document rules, both technical and businesswise). But the vast majority of users are in large to small companies (go figure), and those people need to have a good Word import ability.
--
Evan
:: Groups like OpenOffice, AbiWord, Applix, Koffice, Gobe, and the Mozilla group should get together and establish a workable XML based open standard. Maybe if papa Microsoft let's them Corel(WordPerfect) might show up. Don't even invites MS - if they ask nicely to be allowed to attend then maybe ....
Yeah! And you know what would be cooler? Is if we all got CAKE!!!
Seriously. This is a great idea in an ideal world, but it's not gonna happen. At the very very least because there is too much content wrapped up in Word documents at the moment. There is a great inertia, and if you can't bring your training *or* your content over, switching to a different office suite has no incentive. As it is, the training has to be redone constantly (new versions, new employees), so retraining to KOffice is not a tremendously big deal. After all, KOffice, WordPerfect, MS Word, Abiword - to someone who wants to write pretty text, they are all pretty much the same. Drop down of fonts, and four buttons, one with a bold "B", an italic "I", an underlined "U", and one with a picture of a printer on it. It's amazing how many people don't know how to cut and paste, drag and drop, use undo, or anything like that.
But they use "That file on K:/Betty/" to file for a client who wants to do foo. I've been in an office where they used chinese documents, and nobody spoke chinese - they just printed out the one that corresponded, without knowing what it was, because "that's what you do".
It's much easier for single users and extremely large corporations (who already deal with structured document rules, both technical and businesswise). But the vast majority of users are in large to small companies (go figure), and those people need to have a good Word import ability.
--
Evan
"Yeah! And you know what would be cooler? Is if we all got CAKE!!!"
I'll see what I can do. (wink wink)
I second this. We don't need MS Office crap. Those companies who need it are very much welcome to implement MS Office filters in KOffice. I don't need this shit. Opensource standard is the right way. You are going to waste your energy on MS Office 97, 98, 2000 filters, and then Microsoft is going to change its own standards, and you are going to waste your energy on developing new filters and so on. One example: one of my friends had an Access file created in MS Office 97 (Access 97), and he asked me to change it a little bit (just fonts) and save it for him. I (arggghhh) installed MS Office 2000 Professional, opend his database file, changed it and tried to save it. I got this error: 'This database has been created in older format, you can view it but not save changes'!!!!! What to say?!
And another thing: I doubt that machines (hereby also computers) will ever be able to do grammar checking. Fortunatelly there are no rules for human language
(human language is poetry, slang, philosophy, emotions - not commands).
P.S. We need more Rosies :)
Grammar checking has nothing to do with style. Most people confuse the two. Grammar checking is useful in environments where clean, concise wording is important. As I have Majored in English, I can verify that the average person is denounces style in writing is actually confused on what they are talking.
This is because they lack the knowledge and make assumptions. They didn't pay attention in class when the teacher discussed Passive Voice verse Active voice.
And there I go and make a mistake...
"average person is denounces style" haha
developers, are you listening?
These filters are just as necessary as filters for other Office packages.
How are you else able to run Linux on the desktop in an MS Office environment?
Besides: there are a lot of people still in the dark who prescribe that documents are delivered in MS Office format.
Compatibility is essential, because when compatibility is reached there is no need anymore for a lot of companies to hold on to closed source Office programs. And licence costs drop dramatically. When looking at the numbers it is worldwide ca $ 500 million on Office licences if not more.
What a lot of companies and/or countries could do with (a part of) $500 million... Schools, hospitals, infrastructure (roads, railways and telecom), less layoffs etc., etc. So it's even good for the economy.
Therefore: make KOffice compatible with the rest of the world (yes, even MS, but watch out for beartraps).
just my 2c.
Erick
There is already a combined effort to develop MS im- and
export filters. For more info please read the underneath
mentioned messages:
http://lists.kde.org/?l=koffice&m=99929179819041&w=2
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wvware/wv2/
>
> These filters are intended to be shared by KOffice and AbiWord (at least),
> and will have import and export capability. Write to me privately, and we
> can figure out a good place for you to start!
http://lists.kde.org/?l=koffice&m=100046338303283&w=2
> > A single filter source-pool for all opensource projects would be
> > wonderful to achieve.
> >
> > I honestly believe filter quality/completeness is one of the largest
> > barriers to acceptance of koffice/open office/gnumeric into the larger
> > business eviornment.
>
> FWIW, such efforts are already underway for the editors over at
> wvware.sf.net, and I would would certainly encourage the other apps to do
> the same. Note that is it essential that we all use a generic framework, as
> well as individual filters in order to support embedding.
>
> The work on libwv2 is intended to be supplemented by libwmf2 for image
> handling.
Perhaps we should invite Microsoft to add KOffice import filters to MSOffice and distribute them as an update to their current office packages. It would be good publicity for them, showing the world that they can exist in a spirit of co-operation with others, and of course good for us KOffice users. OK I know that this seem unlikely, but it just seems like a good time to drop anti-microsoft destructive rhetoric, define ourselves by what we like rather than what we hate and invite co-operation on that basis.
I totally agree we need open file formats, I have been saying
this for a while now...you can read my post about it on slashdot:
http://slashdot.org/comments.plsid=21178&cid=2243938
the OpenOffice project already has a start on such a thing
here:
http://xml.openoffice.org/
I think maybe we should start an Open File Foundation (OFF)???
and try to get as many different office suites involved like
KOffice, OpenOffice, Abiword, Gobe, Hancom, etc...
It appears to me that what is needed is a way to import a document created in another word processor and preserve all of the formating information.
To me, what would really be useful would be an import filter for: PDF and EPS files (perhaps one that could import PS files would also be useful to the extent that this is possible).
Since, for reasons I do not understand, people continue to distribut documents in the native format of a word processor (something that I never do), it would also be helpful if there were an application the worked with GhostScript and WV that could convert a MS-Word document to either EPS or PDF.
Well, the problem with that is, PDF loses a bit of magic when you convert files to that, both from MS-Office (no more OLE) and from KOffice (no more kparts). PDF and EPS are really only good if you want to preserve an exact printout, which is often the case, but for when you want the reciever to be able to edit the file easily...
What's even worse is, MS standards for PostScripts (and PDF, which is somewhat similar, iirc) differ from everybody else's. Last I heard, some implementations manually set a coordinate for each characters, rather then for groups of text, making parsing and editing a big fat pain.
What I am (or was) refering to was sending someone a document, not having several different people work on it in the office. Do you really want to send someone a document in a wordprocessors native file format? I realize that MS seems to encourage this behavior, but is it really a good idea?
And how is OLE going to work with a system that uses real object/component software? Remember, OLE is not component software, it is just a simulation.
>>> That is another issue with Koffice. Why, if this is really going to be component software, do the different applications have different file formats, or do they? -- they have different file extensions!
Apparently from what you say, M$ has E3'd PS and PDF as well. This clearly presents a problem.
I still think that Koffice should encourage what I feel is the correct action, senting a PDF of the document. So, it should have an import filter for PDF, and to me, this is more important than a M$-Word filter.
When ever someone provides me with a (M$) DOC file, I advise them that a PDF would be better. Quite often, I find out that they are one of those Windows Addicts that don't even understand what a file format is.
In any case, this feature would be handy so you could load a PDF document into Kword so that you can mark it up.
PDF seems to me the same bad like DOC.
Maybe it's just me but I have to wait _very_ long when I need to load pdf viewer, in Linux and in Windows too.
I believe that _if_ you really need to send some document to someone, you should use HTML filter...
I am sorry but I don't feel comfortable with PDF and I never will..
James Richard Tyrer wrote:
It appears to me that what is needed is a way to import a document created in another word processor and preserve all of the formating information.
To me, what would really be useful would be an import filter for: PDF and EPS files (perhaps one that could import PS files would also be useful to the extent that this is possible).
----
PDF, EPS, and PS would deffinately NOT be a file type to do that. They can provide a picture of the document (fine for distributing it for viewing only) but are not intended to reconstruct the document in another word processor. You can make a file that prints pretty close to the origonal from them, but they cannot have named styles and other things that word processors know about the document while you are working on it.
Unfortunately, there is no fully generic word processor transfer file type. To create one would require a change anytime any word processor added any significant feature.
Word's DOC format is commonly used for transfer, because it is the most common format.
>(such as the ability to import VBA (Visual Basic for Applications) scripts).
Yes, VBA is very used (also with ODBC to work with data bases, and not only
in Excel, also in Word) , and the KDE Office does not seem (?) to find
it is important...
I think that the first goal is to allow an automatic import of the VBA scripts.
The choice of the language is secondery. I don't think that the basic language
is to be rejected by principle, it is a language among others languages (and a
basic language may be better than VBA)
If an import in Python is possible, OK, use Python. If it is impossible, please
work with the KBasic team...
I hope that a policy will be defined and shown in the KOffice site. More
generally, I wish that improvement priorities would be shown on the KOffice
site...
A choice may be, of course, that a VBA scripts import will not exist, excepted the arrival of some strong developpers...
Lets not forget that this review is comparing a v1.1 product against a v10 product. Considering the difference in development time/effort, KOffice is a stunning success so far.
I think it's encouraging that people are able to post 'reviews' like this. Even if most of it is focusing on what's missing, it does mean that here is a product people are capable of actually using.
Well done KOffice team!
Macka
I completely agree with you, but please remember that in the business world they don't care about version number and how far a product it has come in such a short time.
When you buy something, you want to buy the best now! KOffice has to be the best solution now, or it will not be taken seriously. KOffice just needs more time and it will mature.
I think you put it very well. KOffice has turned out extremely well, especially since that dreadful 1.0 turkey.
Another point, though: it's interesting that people compare KOffice with MS Offfice. I think it's unavoidable, considering the name, but it's not really fair at all. Compare it with Works instead, and suddenly you get a lot of power for your money ;-)
As it is, I use KWord on a daily basis, and I would recommend it for ayone with basic writing and DTP needs. For my more complex needs, I still resort to StarOffice.
KSpread also works very well, but here, I've had some rather serious importing concerning Excel. Partly, I think it's due to Excel allowing almost anything, even when it shouldn't be possible :-)
KPresenter is OK for most needs, but I have problems with some of my PPT presentations.
On the whole, I'd say that KOffice is a fantastic bargain for all home users, schools and other places where money matters, and you don't wan't to go through the work to install Star Office.
(Especially when it comes to schools, I would almost call it a crime to use public money to teach innocent children how to push all the right Microsoft buttons :-) )