Slashdot Mirror
ZDNet Reviews KOffice
Spotted over at dot.kde.org -- this review of KOffice. The review isn't overwhelmingly positive or negative -- seems like a rather balanced picture of both what's up to par, and what's still missing, for mainstream acceptance in the Normal Workplaces of the world.
If you don't like reading a three page article by starting on page two, follow the link: *click*.
According to Sun's StarOffice FAQ:
a q.html#12
12. Is StarOffice 5.2 software written in the Java language? Will Sun rewrite the StarOffice suite in Java technology?
StarOffice 5.2 software includes components written in the Java language, and provides the Java Virtual Machine for running software based on Java technology. However, the majority of the StarOffice 5.2 code is written in C++. Sun does not intend to rewrite StarOffice 5.2 in Java technology. The Sun Webtop architecture relies heavily on Java technology for the interaction between the browser-enabled client and the application services running on the portal.
The FAQ can be found here: http://www.sun.com/software/star/staroffice/5.2/f
Unfortunately, I can't get the latest Koffice to run, cause libkprint or something isn't right. A botched kde2.2 upgrade has left my linux box moderately unusable. However, I've used previous Koffice in the past, as well as StarOffice.
StarOffice kinda sucked with the whole 'desktop' thing, and I was much more eager to use Koffice day to day when necessary. But I've noticed that StarOffice seems further along functionality-wise, and the latest OpenOffice downloads seem to be coming along nicely. They've lost that 'desktop' thing, and the components will all be 'single app' programs - definitely a good move, imo.
Given that the OpenOffice/StarOffice platform seem to be much more cross platform than the KOffice stuff, could we not see some merging of the projects, if only complementary filters to import/export each others' file formats? Maybe this is being planned, but it's not something I've seen touted. What I like about StarOffice the most is the promise of cross-platformness. I can work on my Windows OR Linux machines (maybe Mac too, haven't checked) without worrying about learning new interfaces or file format problems.
creation science book
M$ Office: $200-300
K Office: N/C (comes bundled with various distros)
That in itself is an important feature...
You're using her as bait, Master!
...KOffice/Kword to make a big hit with users:
1) Allow reading/saving of documents as *.rtf
Rich text format seems to be the preferred document format among open-source word processors, yet KWord still lacks this feature. Heck, even MS-Word can read and save RTF! Supporting a common document format--instead of just *.kwd and *.txt--is going to be important for interoperability with other OSS office suites and the MS-Office world. Same goes for spreadsheet and presentation graphics file formats.
2) KOffice needs to have provisions for English measurement parameters in KWord and its other products. Yes, the geeks out there can convert to mm, but if you wanna get users off MS-Office, simple features like this will be important.
oh really? [I admit I'm pretty uninformed] but I was under the impression that it was written with Java - which is why I thought it was so slow and clunky. Hmm... wonder what they're excuse is now? Overall I have no problem with star office... but having loading race between Mozilla and Star office is like watching a tractor pull with all the vehicles stuck in neutral.
Im still locked into m$ office for exchange server. Until someone comes out with an Exchange klone, m$ will dominate the market.
We had to install citrix clients so our NOC (running solaris on ultra 10's) could access the exchange servers. Even thou we don't use m$ products for our NOC, m$ infiltrated it via exchange.
E-Mail is at least 25% of my job, working on projects around the country, email is my ball and chain to the m$ platform. All documents open fine under StarOffice, but I still have to go back to exchange for my email. So I just run win2k on my laptop, use x-win32 for display, and samba to mount my solaris box and ssh to encrypt it. Basically Merge the two OS's into 1 via network tools.
I thought the article was very fair. It didn't seem to expect the world out of KOffice, and made the point that it was a volunteer effort.
Having recently fired up KOffice for the first time since the 1.1 release, I've got to say I'm really happy with where it's going. The team has done a great job on getting component embedding working (although it crashed on me when I started pushing it around a bit) and I really think this will shape up to be an incredibly powerful suite.
Of course, these things don't happen overnight. It took Linux about 8 or 9 years to start gaining more widespread acceptance in the server area. KOffice is a tremendous project, and it'll take a long time to get to the point where it can compete with MS Office. Remember, software like this doesn't just happen overnight, it has to evolve. MS Office has had over a decade to get to where it is. I have a feeling we'll start seeing KOffice as a real alternative to MS in a few years.
"I may not have morals, but I have standards."
Comment removed based on user account deletion
Many of the issues addressed should be easy to fix. The lack of an automatic spelling checker and a thesauris in KWord, for instance, should be easy fixes. Likewise the case sensitivity in the spreadsheet program, though most UNIX people won't tend to view that sort of issue as a bug. The customer is always right and all that.
On a quick side note, I still prefer TeX/LaTeX over any GUI word processor I've ever run across. I believe our documentation people 'round these parts still use SGML. Not something a normal user will ever look at due to the learning curve, but once you get a set of styles down, you can rattle off any old document you deal with on a regular basis with almost no effort devoted to the formatting of the document -- you just work on the content.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
KOffice does offer some benefits over StarOffice. KOffice is natively compiled for the machine platform on which it is executing, whereas StarOffice is a Java-based application. This means KOffice responds much faster and is less memory-intensive than StarOffice.
... since when?
Uh
Not even close, ZDNet, but thanks for coming out!
I've just started using kde again after not seeing it for almost two years. I'm quite impressed with the way it has developed, but have a few feature related questions.
I've never really been one to use a file manager, but after setting my desktop to be my home directory, i've started using the desktop, something i've never done with any wm. The problem is that in order to get into any of the directories, you have to start a file manager konqueror session. Is there a way that the desktop itself could be a simple file manager that would changer directories. An extention to this would be embeding a term in the desktop that would let the desktop be the current directory.
Now that we have gotten a very easy to use gui, i think we should try and move it towards the 'unix way' of doing things. This would appeal the the 'power users' as well as the beginners.
My Slashdot account is old enough to drink...
from the article:
/ fa q.html#12
"KOffice is natively compiled for the machine platform on which it is executing, whereas StarOffice is a Java-based application"
from the StarOffice FAQ:
However, the majority of the StarOffice 5.2 code is written in C++
http://www.sun.com/software/star/staroffice/5.2
Why do some many people think StarOffice is written in Java? Is it just because its from Sun?
--
I wish i knew how to get slashot in light mode without having to login
What metric do you want them to measure against? AbiWord? Gnumeric? Better to be compared to what has become the business world's standard and fall short than be compared to something virtually no one else uses and shine. If the standard is to have functions be case-insensitive and you don't follow it expect to be called on it. Expect the normal user to want it to be "fixed." They note that no other competing product uses case-insenitive funtion names so I would place the issue on KOffice. That's fair.
I don't want knowledge. I want certainty. - Law, David Bowie
Lost productivity time due to malfunctioning import filters: Priceless.
-
Thats about all there is in the article. If it took the author more than 4 hours to produce this I would be surprised. Fortunately, the geeks can now read this synopsis instead of reading the author's wordy version. This way we will save hundreds of geek hours.
how big is MS Office? more than 20 times that size. How much cheaper are embedded devices suitable for running KOffice than MSOffice? How much cheaper are 32 MB flash chips than 256 MB flash chips - a LOT. obviously the WinCE versions of MS Office are smaller than MSOffice pro... but they also lack a lot of the features. perhaps a better comparison is WinCE Office vs. KOffice...
-sam
The REAL sam_at_caveman_dot_org is user ID 13833.
No...
They're reviewing it from the point of view of the typical user.
I'm as pro-unix and pro-case-sensitive a guy as they come, and even I wasn't expecting that to be case sensitive. It makes absolutely no sense, unless there are cell rows called 'a' and 'A' (hint: there aren't).
The fact that this is no longer true in current Kspread builds attests to it's pointlessness.
Now you and I both know that KOffice isn't nearly as polished and powerful as MS Office is (and Office XP is going to be).
But the thing is, when you look at how far KOffice has come in how little time, it becomes apparent that it's just a matter of time before it catches up and, provided its leadership isn't content to be "as good as" Office, surpasses Office in features and functionality.
It's the sheer rate of change and speed of development of KOffice that amazes me. In a couple of years, this free alternative to Office will most likely be at least as powerful as MSFT's product, except that it will cost nothing.
Office software is becoming like text editors and browser software: It's something you don't expect to pay for. And if MSFT continues to try to charge people for it, people will move over to the alternatives.
No, it ain't there yet, but look at where it was and where it is now. Look at how short the time was for it to get here.
And just think. Just a few months ago, people were saying that Linux would never be a viable desktop OS. A few who have their heads in the sand still say it. But it is viable now! Even my Dad, who usually lacks the time to learn anything more complicated than instructions written on a sheet of paper that he follows to the letter, could install and get running with KDE under RedHat.
All that's left is a Quicken alternative.
Any novi programmer can do that
I assume you meant novice. In which case, does this mean that the KOffice programmers aren't even up to the level of 'novice'? Come on.
Yeah - just tell people to remember to always hit SHIFT before referencing any cell names or functions. But don't hold it down all the time, or ALL your text will be caps, and it'll look like you're shouting.
Isn't this what a computer is supposed to do? Take away the trivial, mundane tasks like figuring out what function I mean whether I type SUM or sum? I'm sure many think this case-insensitivity thing is some sort of Microsoft strike for world domination, but perhaps they do it (and most everyone else did before them too) because it MAKES SENSE. But since when has MAKING SENSE had much to do with most Linux programs anyway, right?
How about you just CODE it to be case insensitive. Since it's so EASY to change (OPEN SOURCE!) any Lunix geek that wants to remember to hit SHIFT when typing certain functions can just change it themselves and recompile the program. Come on - any novice can do it.
creation science book
It is unfortunately really. If you read the second page of the review, the first thing the authors test is functionality to communicate with M$ office file formats. If that is to be the first level by which KOffice is judged, it will never succeed (in their minds). Unfortunately, M$ has made a business of beating competition by (among other things) keeping file formats different. We need to judge the functionality of KOffice first, its compatibility with M$ second. While the latter goal is important, if we hold that highest M$ truely is the monopoly we accuse them of.
-Sean
I think it would be much better not to claim head-on competition with MS Office. Instead, produce nice, usable, stand-alone applications and think carefully about how to allow people to integrate them.
Exchange does something other mail servers don't do. And it does it well.
I was going to say "groupware". But that's a bit of a misnomer. It does have various groupware functionality - but its specifically scheduling that it does well. Other groupware aspects are almost a brief afterthought.
Sure - there are other scheduling competitors out there. But I watched Cisco Systems gravitate towards Exchange despite their heavy investment in a Unix mail infrastructure and the problems a diverse desktop OS user base causes for functionality with Microsoft products (Cisco endorses Win2k, Solaris, and Linux as supported desktop options for their employees).
Its a shame that Exchange forces one to pick up all the usual MS bagage along with an otherwise top tier product.
Personally, I thought the review was fair from a day-to-day non-computer-savvy-user's point of view. And since this type of user most probably is the intended end-user of a product such as KOffice, the developers should probably take ZDNet's little nitpicks to heart and make their program a better one.
A case in point:
Unfortunately, performance of this component proved troublesome. Trying to get the software to compute a basic SUM() function on a range of cells yielded an error. We later found out that, unlike in Excel, function names in KSpread are case-sensitive, so typing "=SUM(A1:A15)" in a cell yields an error while typing "=sum(a1:a15)" does not. This is a major shortcoming for anyone who has ever used another spreadsheet, including Lotus 1-2-3 and Quattro
Maybe this is one piece of criticism KOffice-programmers might want to take to heart. The difference between Excel being case-insensitive and KSpread being case-sensitive is one example of how people programming for a commercial entity take a slightly bigger interest in the needs of ordinary, non-savvy users than Open Source developers. It's a minor point, to be sure, but how often have you heard the myth flaunted that "the computer crashed because I got one comma misplaced"? KOffice, for now, exhibits some of this behavior, while MSOffice, for the most part (day to day tasks) does not. This is not surprising, as M$ probably spends a large amount of time and money on testing on "ordinary users", whereas the KOffice people don't (can't afford to), so I'm not blaming the latter, but rather, urging them to do something with fair bits of consumer feedback like this.
News and bla for computer musicians: http://lomechanik.net/
StarOffice 5.2 is so resource-hungry and slow that it might as well have been written in Java 1.1. Waiting a solid minute or so for it to fire up on a P2/300 with 192MB RAM, and running into its native widget set, it's easy to unserstand why someone might think it was written in Java. Less easy to understand is why ZDNet seems to have fired all of its fact-checkers.
The OpenOffice development snapshots are definitely peppier, so StarOffice 6.0 should be fine in this regard.. but 5.2.. eek.
Where Java does enter the StarOffice picture is that 5.2 has an open interface that lets you pick a JVM--or install one--to use as yet another macro language. This is a nice touch for all the Unix shops and others that have Java programmers on hand more readily than VBA people. You can use a nice, fast 1.3.x JVM with it, and develop with your existing tools and components. The other nice "Java" feature is SO 5.2's ability to use JDBC throughout for database access instead of native drivers or ODBC. Very useful and very elegantly cross-platform on Sun's part.
And incidentially, the "other" major SO5.2 scripting language is a VB clone, both in syntax and coding environment. SO has a different document object model, so MS Office macros won't run unmodified, but at least VBA skills can carry over. KOffice's use of DCOP for automation allows the use of any available language, potentially doing things one better--but without integration with a development tool as one gets with VBA and StarBasic, it remains at a disadvantage. Maybe bidirectional KOffice-to-KDevelop hooks (for C++) and KOffice-to-Netbeans/Forte (for Java) are a way to go.
The alternative -- an open office product -- will require training 99% of users at a cost of 1,000 to 2,000 per user for the class plus 2 to 5 working days (add another 1,000 for a low estimate. On this model -- the free product cost about 2,000 to 3,000. Sounds like $600 or so for full MS Office is cheap.
Take it out further -- if you are a 100 person company (user base for office product suite) this means MS Office costs 100 x 600 -- $60,000 plus 5 users out to training (those not already trained) $15,000 -- which means that MS Office cost you $75,000 -- not a small chunk of change. Of course the alternative will cost you $297,000 and the skills are not usefull for your workers in later life.
Of course this all assumes that you will be able to find the training -- not an easy task.
What about the savings in hardware? I'd argue their is little to none now-adays. A business would be foolish to buy less than 500mhz machines which are more than adequate for W2K/XP today. I'm writing this from a 350mhz box and it flies quite nicely with W2K. Kinda slow when running StarOffice under a default X install though (Redhat).
The OS install price and support price are arguably not an issue today either -- most 100 user offices will have at least one mission critical application requiring a windows system -- so your on the hook for licensing anyway (read it carefully...).
Choose an open office product? Risk your job for what appears to be a negative payback in the business world? Why are we advocating this again?
Can anyone give a GOOD reason why the heck you want a file system that is case sensitive ?
Click this link to view it as a single page?
What in the hell is the postercomment compression filter, and why in the hell does it try to prevent the posting of a hyperlink to a single page version of a three page article? WHAT is Taco smoking?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
I know it's not a full suite but I've found Abiword and Gnumeric much better at translations from Micros**t documents and spreadsheets. I'm trying to replace MacOS and MS Office on 300 iMacs with Yellow Dog Linux and some kind of Office-type products and I've tried everything that I could find, KOffice and StarOffice are not cutting it.
100 gig RAID arrays on the mail server, or on the file server... Doesn't matter, you still need to backup your company email wherever you put it.
On the other hand, spell-checking in real-time is no big deal at all, and also a feature that many of us would just as soon do without.
AFAIK the KOffice, OpenOffice and Abiword developers are already working together on filters and such stuff.
Huh? I wasn't talking about trademarks, I was talking about what end users expect when an open source program calls itself "...Office". End users will compare KOffice with MSOffice, because of its name, and KOffice just isn't a drop-in replacement: it lacks some of the functionality, it has a rather different UI, and it can't read/write complex documents in MSOffice format. End users don't care whether this is because Microsoft made its system overly complex, they'll simply say that open source failed to deliver. Call "KOffice" something different, and the reviews will start sounding a lot more positive and focus on the wealth of functionality that is already implemented.
Some posters here have mentioned that the fact that KOffice is free will be a significant factor in drawing people away from Microsoft Office. I'm not sure that's at all correct...A year or two ago, I remember seeing copies of Lotus SmartSuite 97/Milennium bundled with all sorts of PCs (not just IBM PCs), and OEM versions being advertised everywhere for AUD$30 (that's only about US $15).
SmartSuite 97 is probably still ahead of KOffice in terms of compatibility and features, plus it actually contained a famous component (Lotus 1-2-3), and it wasn't enough to stop it from sliding into complete obscurity.
KOffice (and StarOffice for that matter) have probably each got another 2 years or so of catching up before they even get close to where the now extict competitors of MS Office were a number of years ago...and being almost free didn't help them back then either.
Lost productivity time due to malfunctioning import filters
You shouldn't be trying to import a COM serialization (Word's native document format since office97); it'd be almost like trying to import a core snapshot from a program running under debugger control.
How hard is it for Word users to save as text, RTF, or HTML? Most of these free software office suites import HTML and other standardized formats just fine.
Will I retire or break 10K?
Does CSS-2 have headers
You mean the logo and ad banner at the top of every web page, or do you mean "headers per page with page numbering"?
footers
Again, the copyright notice at the bottom, or page numbering?
footnotes
HTML can easily do endnotes, and it can also do parenthetical citations, as you see Slashdot already starting to do with the bracketed hostname at the end of a link.
page-breaks
Manual page breaks cause trouble with the different font metrics of e.g. Times/TNR and Helvetica/Arial fonts from different vendors. The problem of pagination would be better handled by a layout engine that can say "This table must fit on one page" or "Do not break <p> elements such that only one line remains on a page."
As an AC pointed out, CSS2 Paged Media supports many of the features you mentioned; all you need to do is fund a project to implement it.
line-breaks?
I've always used <br /> to create line breaks in XHTML.
Will I retire or break 10K?
"Last Tuesday's Financial Report" is much more readable than ... "fr0123.dat"
So call the file fr0123.dat, but design your filesystem to store a piece of metadata "icon_name" that can hold a longer filename. Use the filename for locating directories and files, but also show the icon name in file pickers. fr0123.dat (last Tuesday's financial report) is quick to type-select and easy to read. Several DOS TUI shells did this. Windows almost does this, except it always computes the filename from the icon name.
Will I retire or break 10K?
frames are a far better layout method!
If HTML frames are so good, why don't popular web sites such as Yahoo!, MSN, AOL.com, ebaY, and Slashdot use them? Those sites mostly use tables or CSS2 instead.
(On the other hand, you might be talking about a different kind of frame. If so, please fill me in instead of calling this comment flaimbait.)
Will I retire or break 10K?
An office suite that can't read MS Office documents is just about as useful as a server operating system that can use nothing but floppy disks.
Most office suites can read MS Office documents, but not MS Office documents saved in the proprietary "serialized COM stream" format, which is almost like trying to open another app's files by reading core snapshots. If you save an MS Office document in a standard format such as text, basic RTF, or MHTML (HTML, CSS, and graphics in a single MIME file), free software will import it just fine.
"A server that can read only floppy disks"? Try "a server that can't read Apple II or C=64 floppy disks because they use a different type of modulation." Trying to read Word documents (which are intimately tied to MS COM) is almost like trying to read a hard drive by removing the platters and placing them in another housing (assuming cleanliness).
Will I retire or break 10K?
given that Word has 90% (or whatever..huge %!) market dominance
On the Web, HTML has 99% market dominance. Plain ASCII .txt has five-nines market dominance; the 1e-3% is largely old mainframes still running EBCDIC.
many of these people know VBA
IOW, you're saying "You can take the VBAer out of VBA, but you can't take the VBA out of the VBAer." To show a VBA programmer that VBA/VBS is considered harmful, put her on Windows 9x (95, 98, ME), send her a memo infected with a macro virus, and then send her a VBS that claims to be another memo.
It's really not VBA so much as the lack of good file and memory protection in the host operating system. VB* just makes it too easy to write viruses and trojans, which has earned it the nickname "Virus Builder."
it helps to be able to send and receive office docs that other people can read.
And HTML+CSS2 doesn't meet your requirements why? Is it too hard to ask your clients to save their documents as HTML?
Will I retire or break 10K?
Some things just become too cheap to meter, and hard drive space is one of them.
If this statement were true, nobody would need gzip. However, last-mile bandwidth has not yet become too cheap to meter. It costs some people $200,000 to get high-speed access because they don't live in an area where the local telecommunication monopolies offer DSL or cable modem service. Ever try downloading the whole set of Windows service packs or a Debian apt-get upgrade over a telephone modem connection billed by the minute (as is the case in e.g. Europe)?
Will I retire or break 10K?
There are so many ways this is just wrong. Word processor should require NO training, and other productivity apps should require very little. MS "training" never ends, but right now KDE's applications follow most of the MS input conventions. Anyone familiar with MS junk will pick up KDE in no time, but will be much happier with the better organization. Those that stick with MS are losing time and money everyday fighting an evershifting and ineficient interface.
If you need "training" to work a word processor, the word processor is cumbersome and poorly designed. I taught myself how to use Word Perfect and Word. Word remains an illogical mess with too little user control and too many second rate tools cluttering up disorganized menues. Word Perfect was easier to learn and did most things better. I have not used KWord enough to really comment on all that it can do, but it was not difficult to learn.
The "features" that most MS Word lovers praise as being the most powerful, and certianly require the most training, is second rate and inconstant. Word 2000 breaks previous macros! Word XP will certianly do the same. So there you are, constantly chasing broken junk that never looked quite right. It's worse than VB. Where is the economy?
Friends don't help friends install M$ junk.
You probably didn't miss something stupid - I probably didn't do it the best way possible. I haven't used ECMAScript in a production sense, only played around with it as a minor part of web development. The sandbox issue I agree with - ECMAScript is much easier to sandbox.
The thing I'm not sure about (and here I'm clearly displaying my ignorance) is what capacity ECMAScript has to pull functionality from other applications. Using IE and VB as an example, I could pull Excel functionality and forms from Office 2000 into IE quite easily using ActiveX or another mechanism. But I'd still be using VB to do it. Can ECMAScript give me an Excel spreadsheet within IE? A lot of the modelling work I do needs to have that spreadsheet functionality. I've had a look through MSDN, but can't find anything beyond the same JScript stuff I used before (dates, simple operators, etc).
I can see that it'd be easier with a DB - build the hooks and display selected structured data in IE. No need for a spreadsheet. I can see forms wouldn't be an issue either - just webify. The simulation stuff would be easy to port, it's the links to the spreadsheet that would be difficult (this example is spread out over 30 sheets with somewhere around 2mil calculations).
Any suggestions? Or links?
This is your life, and it's ending one minute at a time.
The difficulty is that a large part of the final product is the presentation. Presentation not in terms of flashy stuff, but in terms of conceptually mapping things out. This particular model details a process flow and allows users to test various scenarios by changing different elements of the process. Regarding the "links", I was pretty unclear. Basically, there's a dependence flow, where each cell on a spreadsheet is referenced to cells on previous sheets. It's this dependence flow that the model maps out.
I take your point about the spreadsheet being a poor tool for delivering a program, but the problem is it's a strategic model (one of the main value points being it allows users to quickly scan large amounts of numbers and see changes instantly). Without going into too much detail, a DB wouldn't quite fit as well as a spreadsheet for this particular solution. It would in most others I can think of, but not here.
Something you mentioned that I'm curious about is "plugin that has a DOM". What's an example of such a plugin? I'd actually love to move to a browser interface and dump Excel VBA - one of the problems I've identified for the future is one of technological lock-in - they're stuck using Excel for the life of the Model (probably about 5 - 10 years). A browser interface would solve the issue of platform independence while also allowing a much more flexible approach. Have you got any links about plugins under ECMAScript?
This is your life, and it's ending one minute at a time.
Basically, there's a dependence flow, where each cell on a spreadsheet is referenced to cells on previous sheets.
The Free Software Foundation has a dependence flow manager that can track dependencies between objects in a filesystem and can call programs to re-create files when the files they depend on have changed. This tool is called GNU Make and comes with most distributions of a GNU system or a GCC development environment.
I'd actually love to move to a browser interface
And you can with server-side Ruby, Python, Java, or Perl. Simply port your simulation to a compiled or interpreted language, create a makefile to re-run the simulation whenever the input changes, and write CGI programs to coordinate the whole mess into a Web application. If the whole thing runs on one box (as is most often the case for a flat-file app), and that box must run Windows, use the Win32 version of Apache HTTP Server, the MinGW GCC distribution (or Cygwin if your app is GPL compatible), and ActivePerl or ActivePython.
Will I retire or break 10K?