Koffice 1.3 Released

perbert writes "On January 27th, the KDE Project released KOffice 1.3 for Linux and Unix operating systems. KOffice is a free set of office applications that integrate with the award winning KDE desktop. KOffice is a light-weight yet feature rich office solution and provides a variety of filters to interoperate with other popular office suites such as OpenOffice.org and Microsoft Office."

Comments

Too many office choices on Linux now!

[ChiralSoftware]

Let's see, OpenOffice, Textmaker, Microsoft Office, KOffice, Kingsoft... what else? It seems that there are now more office choices for Linux than for Windows. Fortunately all except Microsoft Office seem to be moving towards the StarOffice XML format so we can have one file format that works on all of them.

Re:Too many office choices on Linux now!

[grqb]

As a fairly new Linux user, I find that too much choice makes it hard to learn and it's true for lots of other types of software too. I know competition is advantageous and all but I think it would help to focus development on say 2 office choices that were in competition...competition like that between gnome and kde is good.

This can only be a good thing

[Tim_F]

OpenOffice has sat alone at the top of the Free Office Suite application hill for too long. I have been using this product since its alpha stages, and can say without reservations that it has improved by leaps and bounds. The MS Word import filters are alone worth the price of admission (a quick compile on my Gentoo box). The KDE developpers have for a long time now been light years ahead of their open source counterparts. It's good to see that with this release KOffice will finally gain the recognition that it deserves. And with the forthcoming release of KDE 3.2 next week, what more do you need on your open source desktop?

Re:This can only be a good thing

[jrcamp]

OpenOffice has nothing to do with GNOME. It doesn't use any of their framework or integrate any more than it does with KDE. So why do GNOME claim it as their flagship office product? Stick with your Gnumeric et al. :)

Is this Redundant?

[mauriatm]

So which should I use? KDE Based OpenOffice or KOffice?

Previous versions of KOffice left a lot to be desired. And I was finding OO a bit too sluggish on old computers. Abiword seemed to be pretty decent though.

KOffice vs Open Office

[Anonymous Coward]

I find KO to be more user friendly and less buggy than OO. Too bad it lacks the MS compatibilty of OO for Power Point

Speculation

[daeley]

On a Mac OS X note, I'm hoping the speculation is true, that Apple might do with KOffice what it did with Konq/Safari and turn it into the next generation of AppleWorks.

Re:Speculation

[Trillan]

I found a blog entry on a possible Aqua port, but it doesn't seem to be integrated into the builds yet.

Re:Speculation

[Florian]

I doubt that. Apple already has its own presentation program and therefore no use for KPresenter. Despite having greatly processed, KWord still doesn't feel like a production app, has an overally awkward user interface, much inferior import filters to OpenOffice and, at least in the past, insufficient stability. It is therefore not nearly as attractive as the base of a potential "iWord" as KHTML was for Safari. Abiword, which would be an alternative, also lacks reliability and compatibility, and OpenOffice is a monster that Apple would avoid for the same reasons it avoided Mozilla.

Also, KWord is built on top of KDE's component/toolkit architecture that is a world apart from MacOS X Carbon/Cocoa API. While Qt allows a native port to Aqua, it does not offer a native port to Carbon or Coca, and Apple is unlikely to establish a third desktop API on its platform just for the sake of getting a functionally rather limited word processor that, at the moment, has no dramatic advantage over the old Claris/AppleWorks offering.

And keep in mind that for Safari, Apple just used the engine (KHTML) of a free program, not the GUI application (konqueror) itself, in the same way it put its own (proprietary) GUI on top of Mach and BSD. From I experience, I doubt that KWord and Abiword are, in their present state, as attractive as "engines" as BSD and KHTML were. If it all, Abiword seems a more likely candidate since it's designed as a cross-plattform application and, quite in opposition to KWord, focuses on getting base functions and usability right before acquiring more nifty/hackerish features such as frame-based page layout and importing PDF files.

What makes your scenario very unlikely in the end are licensing issues. KOffice and Abiword are GPLed code and thus would require Apple to release any program based on them under the GPL. Which doesn't fit to the company's successful tactics of putting slick, but proprietary GUIs on top BSD- or LPGL-licensed hacker code like BSD and KHTML. A GPLed "iWord" that could be ported back to Linux and even Windows would, unlike the current i-apps, be no exclusive selling point for MacOS X.

-F

Re:Speculation

[LMCBoy]

Since KOffice is GPL, they would be forced to open the source code to their entire application. It couldn't be where they take the LGPL KHTML and link things to it

I don't get it. Why are you so keen to allow a corporation to obtain hundreds of man-hours worth of high-quality code written by a volunteer community, and place that code into a proprietary application? The corporation gets a free (as in beer) codebase which they can then market and possibly make huge amounts of cash, while giving nothing back to the community from which they leeched.

Now, assuming you are not the CEO of the company, why exactly is this a desireable situation again? The above seems like an unequivocally bad deal for the community of developers, and I say, thank goodness the GPL prevents such shenanigans.

since QT is GPL'd... commercial QT applications must pay for a license

If people want to profit from code based on the excellent Qt toolkit, why should they not have to pay Trolltech for the privelige of using their excellent toolkit? TT is gracious enough to allow free (beer and speech) usage of Qt for noncommercial uses, and their commercial license fees are by most accounts very reasonable. It isn't as if they are starved for customers.

You don't have to buy a license for even MS application development

What the hell are you talking about? Assuming you aren't referring to illegal MS application development, can you please explain this? How do you obtain the MS API, core libraries, and development environment without buying a license to use at least soem flavor of Windows, and probably VB, or another MS-compatible IDE as well?

Re:Speculation

[squiggleslash]

If people want to profit from code based on the excellent Qt toolkit, why should they not have to pay Trolltech for the privelige of using their excellent toolkit? TT is gracious enough to allow free (beer and speech) usage of Qt for noncommercial uses, and their commercial license fees are by most accounts very reasonable. It isn't as if they are starved for customers.

Proprietary, not commercial. You can have open source/free commercial software, and non-commercial proprietary software.

Trolltech allows royalty-free use of QT under the conditions of the GPL. If you want to sell your GPL'd end-product, that's fine, as long as the terms of the GPL are adhered too.

Note I am not commenting on how viable commercial GPL software is, merely pointing out there's a difference.

Fun for Gentoo

[GweeDo]

Get the build here

Be sure to do: emerge koffice-1.3.ebuild digest

Then emerge it and enjoy :)

Cross platform = :)

[stfvon007]

I perfer the Open office because its cross platform, as I have a dual-boot machine(well 5x boot) and though I have MS office (needed to get the formatting perfect for those perfectionist profs that ding you for being 1/16 of an inch off in margins (prof required documents be submitted electronicly in .doc format), and for combinations of drawing+text wich open office still dosnt have good compatability with (the text stays in place while the images get all scrunched so they dont match up at all)Its been getting better but is not perfect.

I don't quite get...

[deitel99]

"Especially the support for Microsoft Word 95 and Microsoft Word 97 documents has become much better."

I'm no expert, but considering OpenOffice can already open these file formats quite well (they are old), why does KOffice lag behind? I can understand difficulty in writing these files, but for reading them it shouldn't be nearly as difficult. They wouldn't have to reverse engineer the formats from scratch; they can simply read using the method from the GPLed OpenOffice code. Why the difference exactly?

Re:I don't quite get...

[Just Some Guy]

My understanding is that it's not so much the file parsing that's difficult, it's fitting the resulting data into your application's object model. The KOffice people may have a good understand of the Office format, but it may not be a perfect fit onto their internal data structures.

Re:I don't quite get...

[not_cub]

I'm no expert, but considering OpenOffice can already open these file formats quite well (they are old), why does KOffice lag behind? I can understand difficulty in writing these files, but for reading them it shouldn't be nearly as difficult. They wouldn't have to reverse engineer the formats from scratch; they can simply read using the method from the GPLed OpenOffice code. Why the difference exactly?

Perhaps reading the files themselves isn't as hard as mapping them onto your own representation of a document. OpenOffice seems to have been reasonably like Office from the time I first saw it around '99 I believe (as StarOffice). KDE is effectively a design from scratch, although various things come out working similarly, because they are reasonable design decisions. As a consequence, even though the open world knows the data format of Word files to a large extent, reading them into KOffice is still hard.

This wild guess bought to you by not_cub.

KOffice for OS X still moving forward

[abischof]

And, don't forget that Ranger Rick is still working on porting KOffice to OS X. There are now binaries available and if you're going to download all the KDE-on-OSX packages, you may as well use the all-packages torrent.

KOffice is sweet ready for the Apple picking

[LibrePensador]

Were Apple to do for Koffice what they did for Khtml, and why wouldn't they, the KDE suite of applications would be very much complete.

Koffice, even if it doesn't attract all the attention of OpenOffice, is light-weight and architecturally sound. Koffice 1.3 is almost there, it just needs a little bit of loving care.

If you are convinced that Apple could be interested in Koffice, consider this.

*Qt applications can run natively under OS X.

*The Mac port of OpenOffice is seriously understaffed and very much behind.

* Koffice's code, due to its componentization, is much easier to maintain and to learn.

*It helps Apple maintain its open source credibility, an intangible asset, but one that shouldn't be dismissed.

*It provides a good trump card against Microsoft or at least some leverage to make sure that they continue to put out a Microsoft Office for the Mac.

*It gives Apple greater control over their destiny, which is one of the main reasons why they created Safari.

---Flame retardant suit is on!

Re:KOffice is sweet ready for the Apple picking

[tyrione]

Qt applications are only considered "native" because Apple has caved and renamed the Carbon API as native when, in truth, it's a transitional API that is not the direction of OS X.

Qt would become native if it were written with Objective-C/Cocoa integration, built-in, thus allowing a two-way roadway. Wrapping Qt with Objective-C++ would be a step in the right direction, but so far Qt uses only CARBON.

Apple won't use KOffice other than to study it and from there determine how their own Cocoa Tools may benefit from that experience(s), along-side the AppleWorks past.

Apple should focus on making sure it utilizes a document neutral format, thus XML as it has already done extensively and then provide an API in which pre-existing OSS applications can seemless exchange data while retaining how it operates on the data, uniquely to OS X.

Apple is not in the business of making Operating Systems that make Linux the best choice of Operating Systems, but they aren't in the business of using proprietary data format standards thus extending their past history of isolationism.

pdf read/write support

[esarjeant]

"Also new is the ability to import PDF files into KWord and make changes to the document. Support for Microsoft document- formats has improved as well."

Haven't tried it yet, but this feature definitely peaks my interest.

Try both.

[Balinares]

I think their plan is to use OpenOffice as a stopgap, while keeping the work on KOffice. If you want to know, I used to believe that they were being stupid and should throw their technological knowledge at OO, like everybody else... But after actually giving the latest KOffice a try (I like to try stuff for myself, just to know what I'm talking about), I changed my mind.

I've basically switched to KOffice for my daily use, in fact. It is -NOT- yet as featureful as OO. However, it is so fast, lightweight and efficient (I'm in love with it's layout model) that I'm finding it a somewhat better tool for most of my daily tasks.

I'm not sure they'll ever be able to really compete with such a large, commercially-backed (by Sun) app as OpenOffice, but I must admit I now find myself darn glad they're trying. It'd be quite unlikely, but I wouldn't put it above them to pull a Konqueror in that market as well. You never know.

In the meanwhile, it's damn nice to have a KOffice to show to non-geek people -- especially those who won't switch to OO because of its massive weight and slowness. And if they don't manage it, well at least one can hope the competition will prod OO into getting lighter and faster...

Re:Try both.

[teslatug]

One important thing that OOo has and that KOffice will probably never have is the chance to use essentially the same app across different platforms (Win32, Linux, SunOS, etc). It's sort of like Konqueror vs. Mozilla.

Re:RTF

[Josh Booth]

I agree. Once RTFA is better supported, maybe Slashdotters will actually RTFA when presented in the RTFA format. Wait, RTF, oh...

Re:Open Office Environment

[JabberWokky]

KSpread is fast. Far faster than OOC. It's also smaller. It's a spreadsheet, and there's not much other difference. You can embed KSpread sheets into other KDE apps and view them directly in Konqueror, but you can do that with OO documents as well (there's a kpart plugin for OO.o, although I'm noy 100% certain it's in the main distribution tree or 3rd party).

KWord is fast. WAY faster than OOW. It's also smaller. It is also a completely and totally different type of word processor. OO Writer is more of a MS Word style processor with similar limitations. It is page oriented. KWord is frame oriented, a la Quark and Framemaker. That means it does DTP much more naturally. At the same time it can just give you a repeating frame at the margins and be a pretty typical word processor. Each frame can contain various types of data. The "text" data, aka word processing type stuff, is nicely structured with styles and a style manager. Chapters can be autogenerated, spell check on the fly, and other typical features can be found.

When it comes to a comparison between the two big suites (MS Office, OpenOffice) there are some omissions of features in 1.3 that you might want to be aware of if you do them (stuff like mail merge). Niche office specific tasks. Of course, some of the items like that are missing from OpenOffice as well, and only Word will do. The one that I hear the most complaints about is the lack of a automatic bibliography feature, a la EndNotes. You can, of course, still type them in manually.

KOffice is younger, leaner, and depends on KDElibs for lots of stuff. That means it runs on *nix only... which does include OSX.

--
Evan

Re:Open Office Environment

[CedgeS]

Word Processor comparison:

Word Processors can be divided into 3 groups. Frame and style based word processors are the easiest to use, and the only acceptable methods for large documents. Some word processors include this architecture. Many fall behind, and are nothing more than a glorified typewriter with spell check and editing.

Frame and style based word processors:

Lotus Amipro (NeXT late 80s, Windows circa 1993):
Originally designed for NeXT, along with Lotus Improv as part of an office suite. This is probably the best word processor ever. It is based on frames and styles, and the user interface is esentially three parts: edit text, layout frames, edit styles. Few menus, a bunch of buttons. Surprisingly simple, easy to use, and powerful (comparable to Adobe FrameMaker). Very small, very fast. Puts everything since it to shame.
Annoyances: None
Missing features: Support for new file formats. Fancy text layouts like text on a path, dropshadows, and outlines.

Adobe FrameMaker
Professional desktop publishing program. As the name implies it is frame based. Along with AmiPro and LaTeX it is capable of really professional quality results.

KWord:
KWord lives on frames and styles. It allows text to flow between arbitrary frames. Very good for working with extremely large documents. The styles are one step removed from the user interface, if they came to the front it would be a professional contender.
Missing features: Macros

Lotus WordPro
The successor to AmiPro. Benefits include support for newer file formats, and some new features. The user interface was changed quite a bit to be more like WordPerfect or Word.
Anoyances: Somewhat sloppy UI design, merges are difficult. HTML output is not perfect.
Missing features: Fancy text layouts like text on a path, dropshadows, and outlines.

LyX / LaTeX:
LaTeX does styles extremely well. Is absolutely excellent for anything where you don't need frames (scientific papers, computer manuals, books, etc). HTML output is the absolute best.
Missing features: Frames essentially don't exist.

Word processors that can do frames and styles, but its difficult:

OpenOffice.org
The guiding design principal here seems to be "be as much like Microsoft Office as possible". In this it succeeds fairly well, with a few slight improvements. Styles and frames are far more accessible, but still hidden away a bit to far for my liking.
Anoyances: User interface is a lot like Microsoft Word

WordPerfect:
Frames and styles exist, but they are hidden out of view.

Word processors that can't do frames and styles:

AbiWord:
Last time I used it it was a glorified WordPad or RTF editor. Very simple to use for small documents. Lack of styles made it unaproachable for anything big.
Anoyances: No styles, no frames
Missing features: almost everything

Microsft Write (the dinky text editor):
Fewer features than Word. Easier to use. Results are just as good, and any other program can open it.
Missing features: spell check, almost everything

Microsoft Word:
This one wins the worst user interface award. It has support for styles and frame bassed document layout, but the user interface is designed towards formatting every gosh darn character / word / paragraph by hand. Most word documents are impossible to work with if they have any size. The user interface is so bad that these features might as well not exist
Anoyances: Almost everything. I've used a lot of word processors, from ancient WordStars and WordPerfects to AmiPro. Word has no guiding concepts to follow, either in document design or understanding the user interface. File format incompatibilities between Word versions make it miserable to deal with. Aweful HTML output.
Missing features: Acceptable user interface, functional file format