The fixes were mostly focused on getting list items positioned correct as the rest of the features already worked in 2.0.  Right to left lists are a bit tricky and they were basically broken by placing the counter in the margins.

The following ‘before’ and ‘after’ screen-shots of my test document probably show the progress much better.

First the new status and for reference the old one below. (click to see full size)

Counters in 2.1

Counters with bugs

]]> http://www.koffice.org/background/bugfixing-lists/feed/ 5 http://www.koffice.org/background/what-is-happening-for-koffice2-1/ http://www.koffice.org/background/what-is-happening-for-koffice2-1/#comments Fri, 28 Aug 2009 17:22:05 +0000 Thomas Zander http://www.koffice.org/?p=484 Its been some months since we released KOffice2.0.0, the first official release for the new platform KOffice2.
For common and certainly for advanced office users we made clear that 2.0 is missing features for them. What then, you may ask, is 2.1 going to change for them?
Well, here is what we are working on and what has been integrated into what will become the 2.1 release in a month or two.

Tables
Releasing a word processor without tables was pretty daring, and for 2.1 we did a lot of work to correct this. As part of the GSoC project we got Elvis Stansvik working on this for the whole summer. As this is part of KWord, I was the mentor and near the end we also got help from Casper Boemann. The end result is that KWord can show a huge set of tables based documents correctly. Its important to point out that this is ongoing work; creating new table cells or modifying the shape and look of a table is currently not possible.

Change Tracking
While editing a text document you can always undo your changes and get back to the way your document looked before. But what if you want to show the actual changes made right inside the current document? Or even better, being able to see what your colleague changed in the document over the weekend. This is what change tracking offers and this has been integrated just last week and it looks like we’ll have most of the expected features available in 2.1 thanks to the work of Pierre Stirnweiss. The most exciting part is that this lays the foundations for projects like collaborative editing.

Improved image handling
This has been detailed in another post already, so I’ll keep it short. For 2.1 the images handling has been made faster and we now are much smarter with memory usage so its possible to have image-heavy documents showing just fine even on memory constrained systems and devices.

Continued improvement in OpenDocument Format (ODF) support
ODF is still a huge specification and during the 2.1 time-frame there have been various teams working on testing and improving KOffice to become both better at writing correct and full ODF as well as reading other applications ODF documents. As ODF is a way to inter-operate between different application suites so its obvious that the way to get better ODF support is to collaborate on this front with others.
KOffice has been working at the front-lines with the industry big names for some time now. A recent example is the plugfest in The Netherlands last summer and the upcoming plugfest in Italy where KOffice is well represented.
An exciting initiative is the officeshots which renders an ODF document in all available office applications and shows the output. KOffice has been working with the OpenDoc Society to provide hardware and software support and make sure KOffice interoperability can be verified by everyone.

KFormula major improvements.
The formula editing component in KOffice has seen many upgrades since the 2.0 release. This means that all KOffice applications can now display and directly edit formulas. The GSoC project by Jeremias Epperlein has seen improvements specifically in rendering the formulas much more pleasing to the eye and the editing of a formula is well integrated into KOffice and quite easy to use.

Windows™
At the tagging of the beta1 all of KOffice compiled without problems on visual studio 2008 which significantly lowers the barrier to developer and end user adoption of KOffice. We are still looking for enthusiastic packagers and naturally developers on this platform to help improve the experience for end users.

MSOffice support
Still quite important for many is the ability to open MSOffice documents correctly and the major painpoints are one by one being addressed. Major things like importing text correctly, importing tables and importing images in presentations have been added for 2.1.

Kexi
Although Kexi is continuously developed, we don’t manage to deliver the final version of the application on time. Users are encouraged to stay with 1.1.x series if possible.

Images collection in KWord

The fun begins when you take a look at that “just works” means. For instance, I can have a 1000 page document with one or more photos on each page. Those photos easilly take some 10Mb in memory if they are meant for printing. So obviously the simple solution of just holding your images in memory is out.

Another problem that we see is when a user inserts a photo from his camera into a KPresenter presentation. Then scales it down to only be half the screen width. This means that we’ll effectively be showing the picture at some 15% of its original size. If we want to keep the viewing and moving of things around very nice and snappy, we can’t just scale the image on every repaint, that would be way to slow.

After a couple of weeks of coding we have a quite nice solution in KOffice. I added a KoImageData class which stores the actual image data and is able to dynamically create a scaled down version of that. The actual data we store is in many cases stored in a temporary file on the filesystem and transparently loaded when needed.
This has the directly noticeable effect that if you load a document with loads of images it will be much faster done, and with less memory used. The KOffice applications will no longer parse the image data on load. That will happen later.

My personal usecase is this; I would love to make a collage of loads of pictures of my friends and holidays. And I’d like to do that digitally. Now, when I create a new document in Krita or the Gimp that is full printing resolution of an A4. Then start loading the pictures as layers, it very quickly makes them crash or just get unusably slow.
My ideal solution is that I just start a KWord document where I insert a lot of these images into and I can scale, rotate and move them around very quickly. With hardly any suggestion that I’m manipulating huge amounts of data.
At printing time I’m printing actually to high-resolution images and the resulting PDF can be shown to the printer whom can print it at wanted resolution.
Expect this work work just fine in KOffice2.1

This release is marked not for end-users, then why release instead of wait until its done?

A long and winding road

Indeed, we marked the 2.0 release as not for end users. KOffice has for the past decade been an open source project with the concept of “release early, release often”. This is a strategy that works very well for us. It just feels natural. I think we should realise that in the last couple of years the open source audience has changed. When I did a release of an application 10 years ago the chance of that reaching a user that wasn’t himself also a developer was pretty slim. Now I release an application and some weeks later users that may not even use a command line at all can be using it.

Naturally, this is great news. I personally love it that my software reaches a lot wider audience. On the other hand the concept of release early, release often has a mis-match between what is released and what many people expect from it.

We released because we have to release, its the way that has proven to work very well. Enthusiasts should consider to try the release and tell us what they think, help us make it better. Others that don’t want to live dangerously with their software can wait until its ready for them.

What is a “platform” release?

KOffice2 is a new approach to office components. I’ll write a bigger blog about that later. The big new thing in KOffice2 is a component-based approach, so we have, for example, a text component that is the same in all KOffice2 applications. This component system requires a solid base, a platform as it were. We invite 3rd party developers and interested users to look at our office suite from the perspective of how this platform not only allow an traditional office but also allows innovative new usages for them to build on top of KOffice 2.0.

More to the point; we show things like the kids office plugin that shows integrators and distros a proof of concept that KOffice can be tweaked rather severely. The message is clear; companies that package or sell open source software now have another option to consider for their clients. One that we are convinced will have a lot of potential for them.

When will I, the end user be able to use it?

KOffice 2.0 is a stable release. The features we have should be reliable (not crash, etc.). In fact, version 2.0 already has a lot of features no other suite has. At the same time its missing a lot of features you should really expect from an office suite.

The short answer is thus that it depends. If your office requirements are low, you might very much like the 2.0 release. Otherwise we suggest to wait till 2.1 or 2.2.