The KOffice team is proud to announce the first beta of KOffice 2.0. The goal of this release is to gather feedback from both users and developers on the new UI and underlying infrastructure. This will allow us to release a usable 2.0 release, demonstrating our vision for the future of the digital office to a larger audience and attract new contributions both in terms of code and ideas for improvements. Read on for more information or see the announcement and download it from the release notes.

This is the first beta release of KOffice 2.0, and the first version we encourage users to download and try out. After a very long development cycle KOffice is now in feature freeze. The development team will from now on shift focus from new features to bug fixes until 2.0 is released.

The release team has decided that the following applications are mature enough to be part of 2.0:

KWord, Word processor

KSpread, Spreadsheet calculator

KPresenter, Presentation manager

KPlato, Project management software

Karbon, Vector graphics editor

Krita, Raster graphics editor

The chart application KChart is available as a shape plugin, which means that charts are available in all the KOffice applications in an integrated manner.

Highlights of KOffice 2.0

KOffice 2 will be a much more flexible application suite than KOffice 1 ever was. The integration between the components is much stronger, with the revolutionary Flake Shapes as the central concept. A Flake Shape can be as simple as a square or a circle or as complex as a chart or a music score.

With Flake, any KOffice application can handle any shape. For instance, KWord can embed bitmap graphics, Krita can embed vector graphics and Karbon can embed charts. This flexibility does not only give KOffice unprecedented integration, but also allows new applications to be created very easily. Such applications could target special user groups such as children or certain professions.

Unified Look and Feel

All the applications of KOffice have a new GUI layout better suited to today's wider screens. The GUI consists of a workspace and a sidebar where tools can dock. Any tool can be ripped off to create its own window and later be redocked for full flexibility. The users setup preferences are of course saved and reused the next time that KOffice is started.

Platform Independence

All of KOffice is available on Linux with KDE or GNOME, Windows and Macintosh. Solaris will follow shortly and we expect builds for other Unix versions to become available soon after the final release. Since KOffice builds on Qt and the KDE libraries, all applications integrate well with the respective platforms and will take on the native look and feel.

Native Support for OpenDocument

KOffice uses the OpenDocument Format as its native format. This will guarantee interoperation with many other Office packages such as OpenOffice.org and MS Office. The KOffice team has representatives on the OASIS technical committee for ODF and has been a strong participant in the process of shaping ODF since its inception.

hi,
i didn't hear anything about linuxmce in the past time. is there already someone working on it to get it into shape? the dev-ml isn't saying anything about it. i haven't found any roadmap or something like that...
thanks!

Yes, we agree that the Basic skin currently in use on our Orbiter is not very pretty, we do have the capability for looking a lot better, we just need interested artists to work with us for making a complete replacement for Basic, for not only one target, but 7 different device targets.

We are far superior to XBMC and other "Media Center" solutions, precisely because we are NOT a media center, but a whole house smart platform, and this whole house philosophy extends to each and every display surface in the house, not only TVs and monitors, but:

* Tablets
* PDAs
* Cell Phones
* Touch Screens on IP Phones

and more.

Can XBMC do this? no. not really.

So instead of people trying to scream at us for it being ugly, why don't interested parties come to LinuxMCE, watch the HADesigner screencasts, and help us make a new look?

I'm atm trying to get a media center pc with linuxmce up and running for my brother.. but well.. he HATES that interface and that's the reason he's looking for something else... it feels REALLY slow and looks just plain ugly... well.. we seem to agree on that point.. also it's sometimes badly structured and challenging to use (you get tons of fullscreen messages during install that new hardware was plugged in .. good idea but it should be grouped/...)

No I'm no artist .. I'm just trying to evaluate the problem... as far as I've heard the HADesigner is pretty powerful but it's horrible to work with it .. doesn't make it really attractive for designers who are (at least the designers I know) always a bit shy about software which looks really complex...

So.. what has happend to the plans about UI3 .. there were disussions about it long time ago but it seemed like there was no decision (flash, ...) and so nothing happend.. or am I wrong here?

This post shouldn't be offending .. I'm just trying to find out how the current state of development is

first of all: thanks for notice our questions, Thom.
imho the design is another thing; i just wanted to know whether anyone has picked linuxmce-code up and ported it to qt4/plasma/whatever. once it is in kde, i'm pretty sure that the kde-artists are going to have a look at it ;)
greets

This looks like a fuck-up caused by built-in window$ font rendering routines. I know Qt strives for native look&feel, but... was it necessary to do this with the document view? Isn't it sufficient to use native widgets for the interface, and render the document with some other font rendering engine that doesn't suck as much?

If you have antialiased fonts activated, it will indeed look just like you expect it to. This screenshot was taken on a windows machine that has font hinting/antialiasing disabled. I agree, it was not a very good choice.

Again, letterspacing problems are caused by trying to show on your computer screen what will get out of your printer. Your screen is probably around 100 dpi which means that fonts need to get hinted. Hinting means that the width of each glyph will be adjusted to the screen pixels, so it'll be different than the exact glyph width. And that means that at certain points the error becomes one pixel, which means the placement of the next glyph has to be adjusted to not let the error become bigger and bigger, and that results in either big or too narrow gaps between two letters. Your printer doesn't have that issue since it's dpi is much greater.

The other option would be to turn off all hinting, and then you get a lot of fuzziness, but no spacing problems.

No, this is simply because KOffice strives to show real-sizes. So 100% means an amount of pixels that is equal to a real world size. I.e. an A4 page in KWord is really A4 size on your screen. The slight zoom (0.981 on my laptop) causes rounding errors in Qt to be very visible.

Hmm, I'm quite sure that what I was saying is the real cause. If it shows nice at 100% on your screen I think that's just luck. Move to another screen with a different dpi and it should look worse then (since measured in pixels 100% on your screen would be 98% on another for example)...

The screenshot: "koffice2-beta-windows.png" is certainly not the way that I want WYSIWYG to be displayed. The glyphs appear to be hinted since they are aligned with the screen pixels. I do not want WYSIWYG to use hinted glyphs.

I trust that you are knowledgeable. However, the issue exists that: 1) Hinted at screen resolution & 2}) WYSIWYG are mutually exclusive.

Hinted at screen resolution normally makes the lines longer. So, it you are going to use hinted glyphs with the same metrics as WYSIWYG, you are going to have spacing issues like the screenshot. Whatever the cause, there needs to be a way to fix this problem.

i have to agree: if i had to choose between almost unreadable fonts (try to identify all the whitespaces in the screenshot) or a non-exact size, i'd choose the non-exact size, especially if that's what other word processors do too.

btw, just out of curiosity: how come this problem is so hard to solve (eg not by just using a greater precision in the calculations) ? It seems to me that moving some chars 1 px to the left / right would make the text readable, so it is not yet the "half a pixel" problem here.. I'm not implying here that i think it is a simple problem (i know problems sometimes are much harder than they look at first sight), i'm just a bit curious ... Also i guess scribus avoids these problems because they are using a whole different mechanism of font rendering ?

My favorite part of koffice is Krita it an application that looks and feels really useful. I have not use it alot, but compare to krita 1.X it is capable of so much more. A goof job by all the Krita developers

Pronunciation is that, but I was always wondering why the word processor component had a name so strikingly similar to the most used word processor from a very large company. The similarities between the two programs are dwindling - a new name for KWord would be brilliant. KType? KText? KProcessor?

The problem with Knames (or iNames, Gnames etc.) is quite simple really. Suppose that you have a menu that lists your apps. If they all start with a K, it means that you need to look at the SECOND letter and beyond to determine which app is which.

Take Krunner for example. I use it to launch my apps. With Knames, I need to type more letters for it to determine what app I'm trying to launch, since lots and lots of apps start with a "K".

With more varied naming, the names would be more spread out to different letters, making it easier to select them from a list or launch from Krunner.

Try to simply skip typing the K the next time. I do share your sentiment about the names in menu's, although my default menu doesn't even have the names in there anymore. It is also a bit annoying if you need to edit configuration files: every file there starts with a k...

> thanks really for mentioning the obvious, koffice works for linux either you use gnome or ( insert you favorite GDE)
I think the author is may be talking about QGtkStyle (http://labs.trolltech.com/page/Projects/Styles/GtkStyle. KOffice runs w/o standing out like a sore thumb natively on GNOME.

Two things that kept me away from kword were (1) bad table support; I have never got it right in kword and (2) ugly print-out; a document good looking on screen would be ugly when printed. Have these things improved in kword ?

except for these two annoyances I should say the kword and koffice in general are really great.

Print outs have gotten excellent. This is the main reason I picked up my participation again for KOffice2. KOffice makes PDF creation a first-row-citizen and the PDFs created at least in KWord look great!

Any text problems you see on screen are not present in the PDF.

The tables situation has not improved, we have recognized the problem though and are working on a good way to do tables. I have great ideas on how to do this and work much better using the text layout itself (meaning it will work in all koffice apps).
Unfortunately that will not make it into 2.0 so you will see that tables have gotten slightly worse. I personally think that unless we have something that actually works its not worth hacking together.

There are ~50Mb binary ArchLinux packages, built from KDE SVN trunk every day, for Koffice available below. ArchLinux binary packages are basically tarballs that can be extracted from / (root) on any linux distro, but, some library dependencies could be different. Could be useful for some folks to try Koffice out.

We surely do want to support as much of ODF as possible, but at the same time you have to keep in mind that we have only limited resources. Once we have the time and a reasonable enough idea of how to implement a certain feature, it will get into KOffice as soon as we're done with it.

Hey guys: Does anyone knows if KSpread would have Dynamic Tables with Data Base support . Excel have his Pivot Table, and OpenOffice his Data Pilot (IMHO OpenOffice Data Pilot sucks compared to the "other", i don't know if OO Pivot Table is too slow because of Java or why.).

But that functionality isn't available in KSpread, would KSpread have this functionality?