Go For It!

SVG in Calligra

2011-11-16T23:58:00.001-08:00

Here is a little something that I couldn't resist showing off.

As some of you know, I wrote in my last blog why I thought that the Calligra Suite is the future of the free office suites. One of the reasons was that we use Qt. I have now further proof that I was right in saying so.

The newly released version 1.2 of the Open Document Format specifies that preview images in ODF should be either in the Scalable Vector Graphics format or in a bitmap format (preferrably PNG) -- or both. Calligra has been able to handle that since some time ago and it is available out of the box when the final release is out.

But unfortunately we couldn't handle SVG images as normal pictures because they are handled in the Vector Shape which handles vector images. Preview images are handled in the so called Unavail Shape which handles frame shapes with unknown content. Such content could for instance be an embedded document, something that Calligra cannot handle yet.

This seemed a bit stupid to me since a normal user is much more likely to want to embed SVG images than look at unknown contents with SVG previews. Basically there are no such files out there since the standard has only been out for a month or so and Calligra is the only suite that can generate preview images like that. So I set out to implement it.

And I was done in a couple of hours thanks to Qt. The total patch to support SVG images in Calligra is -- get this -- 160 lines including context. That is ridiculously small for a rather advanced feature like that. I would really like to know how big the corresponding patch for OpenOffice.org or LibreOffice would be.

And as a proof I present to you the obligatory screenshot of Calligra Words with the infamous svg tiger.

LibreOffice and OpenOffice.org: Missing the Big Picture

2011-06-11T06:50:00.000-07:00

For once I will forego a principle of mine and comment on a subject that I'm not immediately involved with: namely the conflict between the communities of OpenOffice.org and LibreOffice.

For readers that don't normally read Planet KDE, I think you will forgive me if I make some references to KDE organizations and applications. Readers that are not interested in OpenOffice or LibreOffice but only in topics related to KDE can stop reading here.

Background

As most of you know by now, Oracle has donated the code of OpenOffice.org (OOo) to the Apache Software Foundation (ASF). Previously it was owned by Sun and later Oracle and released under both a proprietary and an (L)GPL license. Now it will become licensed under the Apache Software License (ASL) only.

LibreOffice (LO) was forked from the LGPL'ed version of OpenOffice.org some 8 months ago, while also creating a new organization for this: the Document Foundation (TDF). During this time the LibreOffice community has worked on cleaning up the source code, integrating features from another fork, (Go-oo, which was used in most Linux distributions), merging features from subsequent versions of OpenOffice.org and also creating new features themselves. They have a healthy community going with a number of core developers (mostly employed) and a large number of volunteers. There is also work on creating a real foundation much like the KDE e.V in Germany, and they received substantial donations to this goal.

To put it mildly, the LO community is not happy about the move of Oracle. Here are some points that are being made:

the donation to ASF is only made to further the agenda of IBM, since IBM is basing their application Symphony on the code of OOo.
the move to donate to the ASF is done to weaken the LO community now that it is starting to see some success.
the code should have been donated to TDF instead since they have all of the community behind them.

I personally don't think many of these points are valid. They have been debunked by clarifications on the Apache mailing lists in ways that at least I think are valid:

The donation was made to ASF instead of TDF because of two main reasons: TDF is incorporated in Germany while ASF is American. Since Oracle is an American company and since the laws are what they are, Oracle would only be able to get the substantial tax deduction that they will if the donation is made to an american foundation, and the TDF uses a license that Oracle didn't want to use (more about this below).
I think that LO indeed has a very healthy community, and it is growing week by week. However, it is self-selected from those that prefer the (L)GPL before other, more permissive, licenses. This means that LO only has the part of the community that is visible, not the actual whole community.
I believe that Oracle doesn't really take TDF seriously. TDF and LO is really big in the Linux community, but most of the OOo users are actually on Windows. I seem to remember that less than 10% of OOo users are on Linux, but I would be grateful for corrections here. I also believe that Oracle doesn't take the Linux desktop community seriously, or at least that they think it is irrelevant to their goals. This means that I don't think that Oracle cares whether they interrupt the LO community or not.

Even though much of the fight has been about the communities, what it really boils down to is a license issue: The ASL is a so called permissive license which lets anybody do almost anything with the code, including incorporating it into a proprietary program or rerelease it altogether under a proprietary license. The GPL, on the other hand, demands that changes are either released with source code and under the same license as the rest of the application, or that they stay inhouse and are never released.

Interestingly enough, the permissive nature of the ASL lets developers of GPL code take code from a project under ASL and relicense and incorporate them into the GPL code. So the developers of LO can take all the changes that are made in OOo and put them in LO, but not the other way around.

Many community members of LibreOffice take this as proof that they are far ahead and that they will always stay far ahead. All the fixes in OOo can be merged with the LO code, but the other way around is not possible. Instead the LO fixes will have to be reimplemented from scratch unless a contributor could be persuaded to contribute to both the projects.

However, all of these considerations are missing the big picture.

The Big Picture

The big picture is that we are all together in a much bigger fight: the one between the Open Document Format (ODF) and the proprietary formats of Microsoft Office. It is petty to say that "we are ahead in this battle, and will always be" when at the same time the whole war is lost.

So here are the facts of the current situation:

Oracle has already made the donation, so there is no chance that they will change their mind and instead donate to TDF. The vote within the ASF to allow the donation into a so called 'podling' is well under way and it looks as if it will be a big YES. There are also over 100 people saying that they will contribute to OOo under the ASF. So it looks like OOo will indeed have a future inside Apache.
Many of the people listed as future contributors to OOo regard the ASL as the best license, precisely because it allows proprietary extensions or even relicensing of the project itself. Among these seem to be IBM who want to use the code as the base for Symphony. These people will not put their weight behind LO which is a GPL project.
The people behind LibreOffice will also not change their minds. For them the GPL is an important way to protect the future freedom of the code. Some of the founders have gone so far as to say that they discourage the contributors of LO to also contribute to OOo under Apache terms. While I am personally very much in favour of the GPL, I think this is a clear case of missing the big picture.

So, here we are: the community is divided into two parts, each with their own agenda but both with a very common interest and common code base (even if in different stage of refinement).

And I maintain that most of the people are missing the big picture. We need to cooperate in some way to win the war. So let's analyse where we can actually cooperate while at the same time keep our priorities in mind.

Common Ground

The most important feature that all office applications have is compatibility. It makes little sense if I produce a document that the recipient cannot load or that loses data when saved back. It is much less important if there is a common feature set in our editors or even if it renders completely the same (this is not true for all applications, of course, but for most).

I would especially stress that data loss is unacceptable.

So the most important thing is that LO and OOo can load and save the same files using the same definition: the ODF specification. As long as this is true, it doesn't matter if one or the other has more fancy features. It is, of course, necessary that they also remain compatible with the Calligra suite and other office applications that use ODF as their native format.

It is therefore important, considering the big picture, that if one of the two suites fixes a bug that introduces an incompatibility, that this fix is also implemented in the other. And not just because LO and OOo should remain compatible, but also in relation to the other ODF suites.

So I will suggest the following...

Compromise

In the Calligra Suite, we have a good separation between the so called Office Engine and the user interface. This engine has the responsibility to load, store, and save the contents of the document. It also renders the document on a canvas that can then be shown in an application for viewing or editing. The separation between the load/store/save parts and the rendering parts are not very strong, but it can nevertheless be seen.

Calligra has had great success with this separation. I think the thinking behind it can be applied to the current situation.

I think it would be of great value if TDF and ASF can agree to let OOo maintain the lower level (the Engine if you like) and then build both applications on top of this engine.

Here is my reasoning:

The war that we are fighting is more important than the license issues. I understand that the people behind LO has little sympathy for the too permissive nature of the ASL and are firmly behind the GPL. However, this should be overshadowed by the importance of furthering the cause of ODF over the proprietary formats that the current monopoly is pushing.
It is very important that different implementations of ODF suites remain compatible with each other. This is greatly helped if they are in fact based on the same code base. It should be more acceptable to have a smaller part of the whole appear under a license that you are not very fond of than the whole application. I think the willingness to do this could be greatly influenced by the current LO leaders, i.e. the people that form the steering board of TDF.
It will save work if we can agree to at least have some common codebase instead of two totally different ones.

I am not familiar enough with the codebase of LO/OOo to give a suggestion of exactly which parts should be shared in this Engine and which shouldn't. But I am confident that if just the will exists to cooperate, then this should be an easy problem to solve.

Calligra is the Future of Free Software Office Suites

2011-05-11T16:58:00.000-07:00

Edit and foreword: Some people told me offline that this blog can be read as aggressive towards LibreOffice. That is not my intention at all. Just look at it as a post highlighting the advantages and strong points of the Calligra Suite. So without further ado...

A couple of days ago Michael Meeks published a blog called 'LibreOffice is the future of Free Software Office suites'. Michael is one of the lead developers of LibreOffice and also one of the founders of the Document Foundation, the organization behind LibreOffice. In that blog he makes a number of points that leads to his conclusion in the title:

LibreOffice is vendor neutral
LibreOffice is robust to participants leaving
Linux distributions are safer with LibreOffice
LibreOffice has a different, and better QA model
Division is (sadly) sometimes necessary
The Document Foundation champions ODF
We are transparent about our contributors

Each of those points is a section in the text. If you haven't read the blog already, you should probably do that now before continuing your reading here. It's quite long but it's a good read.

However...

What is obvious when reading that text is that Michael only compares LibreOffice to one other free office suite: OpenOffice.org. He probably has a good platform to stand on when saying that compared to OpenOffice.org, LibreOffice is more future secure.

But let's examine his arguments in relation to another free office suite: the Calligra Suite (short: Calligra). And more importantly, let's examine what he is not saying.

First of all, all of the advantages mentioned above are also true for Calligra. We don't have the Document Foundation behind us, but we do have one of the largest open source communities on Earth: the KDE community. Other than that, the similiarities are striking.

But what do we have more? We have:

Flexibility
A Clean and Well Kept Ćode Base
Qt

Let's examine them one by one.

Flexibility

The Calligra suite is incredibly flexible. Most of the code form the shared libraries or shared plugins. The applications themselves comprise only a small minority of the total code. Only code that is unique to a particular application is maintained for that application; if anything can be shared, it is immediately moved to a library or a plugin that can be used in all applications.

Calligra also has a strong separation between the engine and user interfaces. This means that it's easy to create new user interfaces for new situations or environments. Today Calligra has two officially supported user interfaces on top of the engine: a standard desktop one and one for smartphones (Calligra Mobile). There is also a new, more general, user interface being developed for tablets and other touch based devices. In addition to that, several companies are at this moment developing their own user interfaces for their own special needs on top of the Calligra engine.

Calligra can be adapted to the needs of new user groups very easily. In OpenOffice.org there was a long-running project called OOo4Kids. This project aimed (aims?) at producing a simplified user interface for kids and took several years to develop. The same could have been done using our Flake technology in 2-3 weeks.

It is also easy to create a subset of the standard features for Calligra by disabling or simply not installing a number of the plugins. If you want to extend Calligra, it is similarly easy to create new plugins and add them to your installation.

A Clean and Well Kept Code Base

Calligra has a clean and well kept code base. This means that code that can be shared is shared. There is no old garbage lying around in the corners. The directory structure is sound.

To mention some things that we don't have:

There are no comments in German that have to be translated.
There are no large chunks of disabled code that was left for future reference because no version control system was used for a long time.
We have one string class instead of five(!).
We have one bool variable type instead of four (of which one can take 3 values).
We have one textbox implementation for all of Calligra and not one for the text application and one for the presentation application.

In addition to what LibreOffice has, Calligra has one very advanced painting program (Krita), one project management application (Plan) and one note-taking application (Braindump). In the next release there will also be a new application for doing network diagrams (Flow).

All of this is created by 1.1 MLoC (million lines of code), as opposed to 5.5 MLoC for LibreOffice, according to the sloccount tool.

This all means that if you work on Calligra you will:

quicker get up to speed with the code base
get more done with less work
have to step around fewer roadblocks
have more fun (ok, this one is subjective)

How much better productivity will this lead to? Let's see in the next section.

Qt

I would wager a significant sum that the main reason why Calligra gets so much done with so little is because of the Qt toolkit, a free C++ toolkit under LGPL. In my opinion, Qt is the best toolkit anywhere for C++, and most likely for any language. Not only is it very, very efficient to work with, it is also very comprehensive and wide-ranging.

And it is developed from the start to be cross-platform. Using Qt means that you will immediately have a head start when it comes to portability. Qt runs on Linux, Windows, Mac OS X and many embedded platforms, and with a native look&feel. Calligra runs on most Unix variants today. It can be built and run on Windows; it is not yet packaged but will soon be.

If Calligra was only using Qt, it would also already run on Mac OS X, but we also use parts of the KDE libraries, some parts of which are not yet ported to the Macintosh platform.

Here are some of the features of the Qt toolkit that we use in Calligra and which applications using other toolkits (or none at all) have to implement themselves:

A graphics toolkit with native look and feel on different platforms.
Platform abstraction.
An advanced UI toolkit with many different layout options that adapt to different dialog sizes.
A dialog builder that can autogenerate code (Qt Designer)
Advanced graphics primitives and paint model.
XML parsing and generation (although we have some code of our own here)

We also use some features from the KDE libraries:

An advanced system for internationalization and localization
Plugin finding and loading
Object embedding, allowing embedding of Calligra components in other applications (KParts)

So how much does this buy us? Let us look at an example.

LibreOffice has a Google Summer of Code project called 'Implementing multi-line edit bar in calc'. The abstract says:

Libre office is an opensource multi-platform productivity suite. Calc is used to perform calculations, analyse information and manage lists in spreadsheets. But currently it is very tedious to edit the cell contents when the contents grows in length. The contents keep spreading horizontally along the single line text input bar provided. The aim of this project is to implement a multi-line re-sizable input bar with a scroll bar and word wrap feature, which when its contents grow will shift the overflowing string to the next line. This will provide easier editing of the cell contents and will provide a more modular user interface.

This sounds like a worthwhile project. To show large formulas in a single line is bad usability. But at what cost?

A Google Summer of Code project is supposed to take a little over 2 months for the students to code, including time to get familiar with the code base and tools. Compare this with doing the same project using Qt: it would be done in 10-20 lines of code as far as I understand. Let's allow for some advanced features and call it 1000 lines. Still a significant difference in effort needed, almost a factor 10. The same difference can be seen in the OOo4Kids project mentioned above.

Conclusion

OpenOffice.org and to a lesser degree LibreOffice have many many more users than Calligra at this point. However, they are all at the desktop using full-sized screens. Because of the big memory and CPU footprint and the heavy intertwining of the UI with the engine they will not be able to adapt to the mobile arena with touch input and much smaller screens in many years.

Calligra on the other hand, already has adapted to those environments. There exists already today a community UI called Calligra Mobile which is well integrated into Maemo 5 on the Nokia N900. This interface is easy to adapt to other operating systems like MeeGo. At the same time, there are several other UI's being developed outside public eyes to be released in a few months.

The Calligra engine is today of high quality and with most of the ODF feature set covered. The user interfaces for the desktop is lagging behind, but the community has just started improving it with the help of user interface designers. To the help we have a clean, efficient code base and the best toolkit on Earth. The community is growing with new developers every week.

This is a race between Achilles and the Tortoise. The Tortoise has a long head start, but there is no way he will be able to keep up with the agility and speed of Achilles. So in the short, maybe medium, term LibreOffice is the future of free software office suites. On the desktop.

In the long run, and already now on non-desktop environments, Calligra is the future of free software office suites.

StarView Metafiles in Calligra

2011-05-01T06:12:00.000-07:00

This blog is a report on a new feature in Calligra that improves the interoperability with OpenOffice.org and LibreOffice.

Background

The OpenDocument Format contains a great idea: so called Replacement Images. The idea is that when you have an embedded object in an ODF file, perhaps not all applications can handle that particular kind of embedded object.

So in addition to the object itself, a saving application has the option to save an extra image of the object alongside of the object itself. That way, the loading application can at least show the contents of the object to the user even if he or she cannot edit the object. The problem lies in the fact that ODF never defines which formats this image can be in. In fact, ODF doesn't even make any difference between bitmap images like PNG or JPG and vector images like SVG (Scalable Vector Graphics) or WMF (Windows MetaFile).

One of the bigger annoyances when interacting with OpenOffice.org or LibreOffice is that they save their replacement images in so called StarView Metafiles. This format is age old and dates back to the old Star Office times when Star Division was still a living company and OpenOffice.org didn't even exist. The format itself is not very complex, at least it's much simpler than, say, WMF or, worse, EMF. The problem is that it's completely undocumented.

I have been trying a long time to find out anything about the format, but no matter who I asked at conferences, in email or in IRC channels, the answer was always UTSL.

Progress

I have been hesitant to UTS since OOo code has a reputation that it's very big and very messy. However just before easter, Pinaraf a.k.a. Pierre Ducroquet started a project to do just that. He did some great detective work and produced a proof-of-concept parser and viewer for parts of the SVM format.

At easter time I got inspired and using his work and my experience from similar work for WMF and EMF in Calligra I started on a real production parser and viewer for SVM. And behold, in 3 days I managed to put together a framework for parsing the SVM records and show replacement pictures in Calligra. Here is a picture that shows the current state of things:

As you can see we can already do polygons, polylines, text and colors. It also does filling and mapping of the image coordinate system to the document coordinate system.

Future work

The main thing still missing is handling of bitmaps. SVM, like other meta formats, can embed bitmap images and also other types. SVM defines a type of embedded DIB (Device Independent Bitmap) that we will have to parse and make into a QImage.

Also, OOo 3.4 that was just released has support for SVG images, a feature which they brag about in their release notes. What they don't mention is that they don't put in pure SVG files as normal pictures or replacement images. Instead they embed the SVG into a very thin layer of SVM. I have no idea why anybody thought this was a good idea, but there it is. For compatibility reasons we in Calligra will have to handle this.

There are also only basic support for many formatting options. We do handle line color, text color and fill color. It's not obvious from the picture above, but there is currently no support for line styles. There is also very little support for different kinds of text formatting like even bold, italic and similar. But I'm very happy with the results so far.

SVM Specification
To fix the fact that there is no specification of the StarView Metafile format, we are creating one as we go along. You will find the specification for the StarView Metafile SVM format here. (Note how I carefully worded the last sentence so that it will be findable by google for anybody wanting a spec. :-) ) At least I hope this is the correct link, I'm not very familiar with gitweb yet.

We will continue to enhance this spec, but it is difficult work because we have to read the uncommented source code of LibreOffice and try to deduce the intentions of the programmers. Help would be very welcome here, also from non-Calligra developers.

KOffice 2.3 beta1

2010-09-17T07:21:00.000-07:00

The KOffice team has just released version 2.3 beta1. KSpread is now ready for end user production work, we think, and Krita is reaching professional quality. You can read more about the release on www.koffice.org. But! To make it really good, you have to test it and tell us about bugs that you find. After all, that is the main purpose of a beta release. Please download it, and test it as much as you can.

New things in the upcoming 2.3 are:

Text on shapes are now supported everywhere.
A new slide sorter view in KPresenter.
Shape animations, also in KPresenter.

There are also lots of bugfixes, especially in the more complex aspects of the text layout. As usual the import from various MS formats have been improved a lot. You can find most of the details in the list of changes.

Akademy!!1!one!

2010-06-30T14:27:00.000-07:00

Since everybody is doing it:

And I'm going to talk about KOffice, so it's going to be really interesting. :-P

And btw, don't forget the KOffice BoF on tuesday in Area 51^W^W Area 4, whatever that is.

Thanks Paul Adams for this high quality banner!

KOffice - Portability in Action

2010-01-21T01:20:00.000-08:00

I have on several occasions been asked "why do you work on KOffice when OpenOffice.org already exists and does everything people need?". Well, there are several reasons why OpenOffice.org (OOo) is not the end-all of free office suites. This blog is the first in a series that will outline why KOffice is necessary and why it may in fact be the real future of the free office suites.

Let's start in this blog with portability.

KOffice runs on all Linux distributions which is not surprising since most of it is developed on Linux. It also runs on Windows and MacOS X, although these ports are not production ready yet. There is still some infrastructure and packaging work to do, but the KDE Windows and MacOS X teams are doing a fine job there. These three platforms are also the ones that are supported by OOo.

But it doesn't end there. Three days ago, a KOffice port to Haiku, the free followup of BeOS, was announced. The porting team had started out by porting Qt, the great C++ toolkit from Trolltech, now owned by Nokia. After that they continued with the KDE libraries and then KOffice and most other KDE applications were just a simple matter of compiling. There is also a port of KOffice to FreeBSD, which is another Unix dialect where, to my knowledge, OOo doesn't work. Edit: OOo is available on FreeBSD as shown by one of the comments, my bad.

KOffice on Haiku

But to make things really interesting, we have to look at the mobile devices. This week we saw the first alpha release of the office viewers on the Nokia N900 device. This release is interesting in several ways. First of all, it's not a normal Intel processor and not a normal desktop or laptop machine with all the power and memory that such a machine has access to. Instead it's an embedded device and demands a very low energy consumption but still needs to provide a fast response to the user.

The office viewer on the Nokia N900 with its custom UI.

The other challenge with the N900 port was that the UI had to be switched for a new one. The desktop version of KOffice uses the normal WIMP interface (Windows, Icons, Menus, Pointers) but the N900 device has a touch screen and a small form factor. The desktop UI would simply not be workable for such a device. KOffice is the only free office suite that allows the developer to use the internal engine for loading and rendering the contents and create a custom UI on top of it.

So, what gives KOffice this great flexibility and portability? Well, first of all it's the Qt toolkit. Qt is arguably the most portable toolkit of all, and especially if you take into account that it provides a native look&feel on all platforms that it is ported to. Qt is ported to all Unix dialects, Windows, Mac, Symbian and many more. On X windows it can even take on the look of the desktop environment, like Gnome or KDE Plasma.

Second, it's the design of KOffice itself. KOffice has a very modular design. Not only is the GUI mostly separated from the engine, it's also very much based on plugins. In some cases even plugins have plugins -- the spell checker, for instance, is a plugin to the text shape, which is a plugin in itself.

The first point makes it possible for the developer to create completely new UI like Nokia did. We foresee KOffice ported to Symbian and other mobile OS'es like Moblin and Android once Google allows native applications that are not written in Java on it. And why not a port to Windows Mobile?

The modular design with plugins makes it very simple to create a tailored version of KOffice with a selected set of features. Right now, there is a CMake option to the configuration phase called "TINY" that creates a smaller KOffice with a limited set of applications and a limited set of filters and built-in shapes. As far as I know, there is no similar build time options to OOo or Abiword. It's also easy to replace functionality by simply switching a plugin to something similar. An example of this is how Thomas Zander created a simplified text formatting docker for kids with fewer options and bigger buttons.

So, the combination of these two makes KOffice uniquely suited for non-standard platforms. Non-standard by desktop standards, that is. Most people today agree that mobile is the future. And maybe so is KOffice...

KOffice and Embedded Objects Part 1

2010-01-10T14:28:00.000-08:00

This is the first blog in a series of two. In this part I will explain how embedded objects are stored in the OpenDocument Format (ODF) and some progress that has been made in KOffice lately. In part 2 I will show what the future has in store.

Now, as you know, any decent office software can handle embedded objects. Such objects can be widely different, from the very simple to the complex. It is the more complex types that I am going to talk about here like charts, music scores or even complete embedded documents.

Here is KWord showing an example document with two embedded objects: a rectangle and a chart:

Let's look at how this is saved inside the odt (OpenDocument Text) file. An .odt file is just a zip archive, and can be unpacked with the normal unzip command:

# unzip ../kword-embedded-objects.odt
Archive: ../kword-embedded-objects.odt
extracting: mimetype
inflating: settings.xml
inflating: content.xml
inflating: styles.xml
inflating: Object_1/content.xml
inflating: Object_1/styles.xml
inflating: meta.xml
inflating: Thumbnails/thumbnail.png
inflating: META-INF/manifest.xml

We have 2 interesting things to look at here: content.xml that contains the document contents, and Object_1 that is a subdirectory that contains an embedded object. Let us start with looking at a part of content.xml. Note that I have applied some formatting on the XML to make it easier to read.

<text:p text:style-name="P1">abc</text:p>
<text:p text:style-name="P2">
<draw:rect draw:style-name="gr1" draw:id="shape1" svg:width="21.36217608452pt" svg:height="31.96877753470pt" svg:y="-31.9688pt" text:anchor-type="as-char"/>
</text:p>
<text:p text:style-name="P2">def</text:p>
<text:p text:style-name="P2">
<draw:frame draw:style-name="gr2" draw:id="shape2" svg:width="226.33462363427pt" svg:height="141.45913977142pt"
svg:x="-57.00000000000pt" svg:y="-42.00000000000pt" text:anchor-type="as-char">
<draw:object xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" xlink:href="./Object_1"/>
</draw:frame>
</text:p>
<text:p text:style-name="P2">xyz</text:p>

Notice the difference between the two objects, the rectangle and the chart. The rectangle is completely defined inline while the chart is only defined as a frame with a pointer to the actual contents, which is the xlink:href within the draw:object. Right now we can leave the actual contents of the files inside Object_1. That is not relevant here.

The interesting thing in the OpenDocument specification is that you can have more than one object inside the draw:frame element. These objects can be of any of these types:

Text boxes
Objects represented either in the OpenDocument format or in a object specific binary format
Images
Applets
Plug-ins
Floating frames

If you do have more than one object, they are not shown next to each other or above each other. Instead the first one that the program recognizes is shown. The rest are just hidden from the user. This is often used by combining a complex object and a picture that shows the same object. The idea is that even if the application can't handle the complex object, then at least it can show the picture to the user. These pictures are often called Object Replacements since that name is used by OpenOffice.org as the name for the directory in the ODF file where the pictures are kept.

KOffice has been able to handle such object replacements for a long time. However all the formats that KOffice could handle were bitmap formats. Bitmaps are good because they are easy to handle, but they are bad because they don't scale well. They become grainy or blocky when they are scaled up and you lose precision.

When you are dealing with MS formats like DOC (MS Word) or PPT (MS Powerpoint), you will find that the same concept of Object Replacements exist there. Naturally MS use their own formats, and in this case the formats in question are WMF (Windows MetaFile) and EMF (Extended MetaFile). WMF is an older 16 bit format and EMF is the newer 32 bit format. Both are vector formats so they are easy to scale and will not lose precision.

I have worked on import of embedded objects a while now and specifically to be able to import and show WMF and EMF. Except for one bug that I know of, I am now done: KOffice can now show embedded objects with object replacements using either WMF or EMF. To import and convert all of the MS file formats is a very big task and I'm sure that in the long run the KOffice team will manage that as well. But already now the users will be able to view any embedded object provided that there is a suitable object replacement. This will be available from KOffice 2.2.

As a proof, I give you this screenshot of KWord compiled from trunk that imports a DOC file with an embedded chart (the bug I was talking about is the text displacement in the legend):

KOffice 2.2 is shaping up very nicely. But it will be even better than this, and that is the topic of part 2 of this series.

Edit: the bug is now fixed.

KOffice @CeBIT 2010

2009-12-29T05:53:00.000-08:00

CeBIT is the largest computer tradeshow in the world. They show everything there, and it's the place to be if you want to see the latest trends in computing.

Last year, Linux New Media AG sponsored a shared booth for a number of Open Source projects. KDE was among the chosen ones, as was Amarok. In 2010, they are doing the same through the Linux Magazine. Here is what they write:

The Open Source phenomenon is what embodies the title theme "Connected Worlds" of CeBIT 2010. The principle of free, open source development as a teamwork of volunteer contributors to worldwide projects has become a success model.

Since KOffice has seen such a fast and powerful development during the last year, we applied for a spot and we got it! I'm pretty sure that Nokia choosing to use KOffice for their new N900 device helped a lot.

This is perfectly timed with our plan to get KOffice 2.2 ready for end users. Linux New Media writes:

After its great success in 2009, "CeBIT Open Source" is getting an encore in Hall 2 with an even larger presence of the newest and most interesting free software applications.

So, when you think about it... With a goal like that, how could KOffice not be among the chosen ones? :-) And oh, yeah, KDE itself is on the waiting list, so we may have two KDE projects in there when the time comes.

KOffice - We Have a Plan

2009-12-15T08:24:00.000-08:00

At the end of November, the KOffice developers met in Oslo for their semi-annual developer sprint. You have probably read some of the many blog entries from that meeting or read some of the news articles that Jos Poortvliet wrote on the dot.

Many things were discussed during the meeting, and one of them is how we can make KOffice mature enough for real users. If you have followed KOffice development, you have probably noticed that in all our release announcements, the latest of them for KOffice 2.1, we always labeled KOffice as not yet ready for real production usage. This is now about to change.

It has long been our hope that KOffice 2.2 should be ready for the end users. Until the sprint, it wasn't very clear what that actually meant. What we did at the meeting was to formulate a plan for what End User Readiness really means and how we will achieve it.

At the KOffice wiki, there is a page which describes what we are going to do. Basically we will use the plan that Krita came up with and use it for KWord, KSpread and KPresenter: Target the application for one specific user and make it perfect for him/her. Then hope that it's good enough for other users as well.

The target users had to be users whose needs are pretty simple. KOffice has a good base to build on, but is still lacking a lot of features. We can't do everything at the same time, so what we have to do is to identify which features to do first and implement them so they are mature. So here is the plan, as described on the wiki page:

We will find so called Target Users for each of KWord, KSpread and KPresenter.
These target users will define some Use Cases that are valid for them. These use cases should be rather simple.
From the use cases, the developers will define which Features the applications have to support to be able to allow the users to achieve their goals in the use cases.
Finally we will keep track of Bugs and Wishes (new features) that have to be fixed or implemented for the features to work.

We have found target users for all of the applications. Notice that none of the target users, except me, is actually a developer. I would be happy if we could find somebody else than myself as the target user for kspread, and will accept volunteers gladly.

Not all target users have written down their usecases yet, and not all use cases have been transformed into features yet, but now starts the work. This page will be a living document, and will guide us over the months to come.

At the same time, we have a gracious offer from Thomas Pfeiffer (colomar) to work with us. Thomas is an interface design expert and has previously worked with Amarok. I hope that he will not find us too difficult to work with over the upcoming months.

Last, but not least, we will also try to make the libraries of KOffice stabilized so that outside developers can write extensions without having to worry about them becoming incompatible with future versions. Wish us luck!

KOffice at the ODF plugfest and ooocon 2009

2009-11-13T07:33:00.000-08:00

I spent the last week in the beautiful Italian city of Orvieto in Umbria, a little over 100 km north of Rome. The reason for that was that something called the ODF Plugfest was arranged by the dutch organization Opendoc Society. The Opendoc Society is interested in spreading the OpenDocument Format (ODF) and in interoperability between different applications using ODF. I was there as a representative for the KOffice community and also for my company KO GmbH that sells services around KOffice and OpenDocument. With me from the KOffice community was Jos van den Oever, also from KO, and Thomas Zander from Nokia.

The plugfest was held during monday and tuesday, and during wednesday - friday, the OpenOffice.org conference ooocon2009 was held in the same city. I missed the first day due to problems getting away from home and also a late flight into rome. The end result was that I had to spend one night in Rome, which normally would be a good thing but was irritating this time.

The plugfest had around 30 attendants, and the OOo conference 10 times more. It was interesting to see all the implementations of ODF, with OpenOffice.org as the largest one and all of its offsprings: EuroOffice, Red Office from Red Flag Linux, Symphony from IBM, etc, etc. KOffice is clearly the second largest free implementation and MS Office is quickly stepping up as a new contender with the tenacious Doug Mahugh as its champion.

As expected, the plugfest indicated that there is not yet perfect interoperability, but it also indicated that every application has been improved since last year. Also as expected, most of the problems were found in less used parts of the standard. Rob Weir of IBM brought a test document for OpenFormula, the formula specification for ODF 1.2. Most applications got good results on that test. Some difficulties arose around the definition of color gradients in ODF, where KOffice implements the SVG type of gradients, which are more powerful, but both OOo and MSO implemented the draw:gradient definition from the ODF draw specification. A lot of discussion came out of that one, which will undoubtly lead to an even better result next year. For some of the tests, KOffice didn't implement all of the features in the test yet (e.g. pivot tables) so we didn't get any good result there.

Something that I found interesting is the respect that KOffice receives these days from the other parties. That is a refreshing change from a year ago when many of our announcements often were met with questions of "why not just program on OOo instead?". All of the KOffice developers know that it's not as mature as OOo. We also know that despite this, KOffice has a number of advantages against OOo, such as a well designed code base, built on a solid toolkits (Qt and kdelibs), and only a tenth of the lines of code despite more applications. It is nice to see that this information has now spread outside the KOffice community as well and people seem to understand that with the current speed of development, KOffice will very soon be a viable alternative for the normal user.

During both the plugfest and, especially, the OOo conference were given a number of interesting presentations. The keynotes talked about adoption of ODF and deployment of OOo. Of the technical presentations, I found especially interesting a presentation about the the next version of ODF (1.2) by Rob Weir of IBM, and also about the next generation after that -- ODF-Next. Doug Mahugh from Microsoft gave a presentation about interoperability with MS Office and some choices they had to make. I gave a presentation about an idea for a toolkit called the OdfKit together with Alexandro Colorado (I will blog about that separately).

No week can be spent in Italy without eating and drinking well. The organizers had really spent a lot of effort (and I suppose money) on bringing good food and wine to the delegates. There was a party every night except friday, and the spirits were always high. During the plugfest we were also given wonderful lunches complete with desert and cheese afterwards. Thank you!

All in all, it was a very good week. The surroundings were very nice, the people pleasant, the food very good and the contacts that were made between the communities were great. The OOo people now know a little more about KOffice, and we know more about the team that creates OOo. I will definitely go to the next plugfest and hopefully KOffice will be able to show off even more features then.

KOffice Sprint is now Officially On

2008-11-07T09:40:00.000-08:00

So, here I am now again at the KDAB offices in Berlin. Once again I'm meeting with Cyrille, Jan, Pierre, Johannes and many of the other KOffice hackers to discuss things about KOffice and get some hacking done. This time the topic is release planning: We want to make using KOffice 2.0 a good experience for the user even if it doesn't fulfill the whole potential of the new frameworks, just like KDE 4.0 didn't fulfill all the potential of the KDE4 frameworks.

To make it clear to our users what they can expect, we will have two parallel tracks here: a technical track that will try to pinpoint all the technical problems so they can be fixed, and a marketing track where we will try to formulate a consistent message about KOffice and KDE on the 3 main platforms: Unix, Windows and Macintosh. For some good thoughts about this, see Sebas' wonderful blog from yesterday.

Marble Code Swarm

2008-08-07T12:39:00.000-07:00

I'm doing the final packing now before going to Akademy, but before that I thought I'd show a little gem that the Marble gang found on the net. It's called project code_swarm, and it creates a video of how a software project was developing. It will show the various contributors and how their contributions vary in size and amount over the time.

Take a look at the "Get Involved" page of Marble and download the incredibly cool video and view it. I'm sure we will see plenty videos like this one in the near future.

And, btw...

OpenDocument is Now a Real ISO Standard

2006-12-01T18:56:00.000-08:00

Yesterday ISO, the International Standards Organization, finally made the OpenDocument Format (ODF) specification into a real ISO standard by pushing the specification into stage 60/60. This means that every government on earth could -- and indeed should -- specify ODF as the preferred format for storing office files.

This is very good news for KOffice since we were the first office suite that used ODF as the default file format and is now only superseded by OpenOffice.org in the support of it. For more details, see: The ISO website about ODF. Of course, it was known for some time that this was going to happen, but it's still nice when it actually becomes reality.

aKademy wrapup

2006-10-05T16:04:00.000-07:00

aKademy is over and it's time to do a summary of it. As most of the
other people I have attended numerous talks, met lots of interesting
and fun people and generally had a great time. But OMG an I tired!

It's interesting to notice that what I thought would be a short
conference followed by a prolonged hack session turned out to be a
week long series of talks, BoFs, meetings, fun nights out but very
little actual programming. People tell me that this is the general
trend for everybody. The first aKademies were real hackfests, but as
the KDE project has grown, so has the number of people attending and
also the complexity of the software. Nowadays most of the time is
spent listening to other people about what they are doing and
coordinating development efforts and sharing experiences with each
other.

So, what have I been up to the last days? I think that I have been
pretty productive, actually. Except for listening to many interesting
talks, I have:

- Held my own presentation about "How to Make Your Program
Popular". Let's see if anybody follows my advice to next year or if
it was wasted effort.

- Done my duty as a member of the KDE e.V and attended the general
assembly.

- Coarranged the ODF day with Waldo Bastian and his wife Tink with
attendants from IBM, OSDL, OASIS and several other important
organisations in the OpenDocument World.

- Formed some sort of relationship between KOffice and a number of
movers and shakers in the same ODF world, for instance OASIS, IBM,
OSDL and the OpenDocument foundation (do you see a connection
here? :-) ).

- Started the formation of a scripted, GUI-less version of KOffice
that the KOffice group will develop the API to in cooperation with
Rob Weir of IBM. This was made possible in a very short time by
our scripting guru Sebastian Sauer who is awesome.

- Talked with the Marketing Working Group, especially Claire Lotion,
about organizing a hack weekend for KOffice 2.0 with an ODF theme
during february next year. This is already in motion, and if we
can just find a good location I'm fairly confident that it will
actually take place.

- Laid out the marketing plan together with Sebastian Kügler of the
Marketing Working Group for KOffice 1.6 that will be out in 2
weeks. Left to be done is to write the actual press releases and
the other announcement documents.

- Talked with the Community Manager of Trolltech about sponsoring and
future interesting projects. Knut is a very dynamic guy with many
fascinating ideas. I'm sure we will have lot of things to work
together on in the future.

- After listening to the lightning presentation of Okular, noticed
that they are doing their own parsing of the OpenDocument format.
Thinking this is a bad idea, talked to a number of people,
including members of the TWG to do something about that.
Interesting things are happening in this area. More about that in a
future blog.

- Talked to the kdegames people about boardgames and some aspects of
it, like AI's, playing on servers, file formats, protocols, etc,
etc.

- Actually done some programming on kchart, my own little application
in the KDE universe.

- Been out drinking and dancing all nights except two during the
whole 9 days I have been here. I wonder if that has something to
do with why I am so tired right now.

And this is only one person! If you multiply this by 180, the number
of attendants, you will get the full extent of what has happened here
in Dublin. I have never seen such a collection of creative, positive
and generally awesome people before. Never!

Given this, and a number of other things that I have heard about here,
I am more convinced than ever that KDE has a very bright future. KDE4
will be out in the not too distant future, KOffice 2.0 will be out,
and the next generation of the free desktop will have arrived.

Last, I would like to send a very special thanks to Marcus Furlong and
his group of organizers who has done an awesome job!

Usability Bugs and New Developers in KOffice

2005-10-27T12:33:00.000-07:00

In a recent blog I mentioned that we now have a Usability component for all KOffice applications in the KDE bugzilla.
The nice thing about these bugs is that, in addition to making the application easier to use if they are removed, they often are pretty easy to fix. In other words, they are perfect Junior Jobs.
Junior Jobs are what we call bugs that are easy to fix, and therefore well suited to new developers. The are a great entry into the often quite complex programs. In Bugzilla, they are marked with JJ: in the title.
In KOffice, we have started to collect these JJs in a special web page at the KOffice web.
So if you are a future KDE developer and agree with us that KOffice is where it's at, then please go to that webpage and pick a task that you like. We will welcome you with open arms. You can also go to #koffice on IRC and talk to us almost 24/7.

Kids Office part 2

2005-10-23T09:53:00.000-07:00

When I blogged about Kids Office almost a month ago, I only wanted to present an idea that I had when I took a shower. It was the kind of idea that often comes to my head in lots of different situations.

I had no idea that it would generate such a big interest from a lot of people. I have received 10 comments on the blog alone, and numerous emails. Some people wanted to know if this was just an idea, some provided feedback on the GUI or the basic concept, and some wanted to know when it would be ready.

Curiously enough nobody offered to help with the coding. :-)

Anyway, it is nice to see that I might have stumbled on something that might actually be of use to people. One of the commenters said: Forget the children. Make this for my 58 year-old mother. Perhaps he is right, perhaps this would also be good for those who don't like to use computers, or are afraid of them.
Not one to let good feedback go to waste, I contacted Danny Allen again, and we discussed what we could do about it. We figured that our target group, kids of age 8-10, wouldn't need a full office suite. A writer application and a drawing application would be enough.

So here is the concept of DrawUp, our drawing application that he came up with. It reuses the button bar that we recognizes from WriteUp, and replaces some of the word processing tools to the right with tools more suitable for a drawing application. Here is the application mockup with an empty document:

It uses the same GUI concepts as the word processor described in my earlier blog: large icons, helpful colors, and less features than the full application. It also introduces some other simplifications. Like for instance this:

When you create a new object, you have some easy choices: a circle, a square, freehand drawing, a star, etc. But Danny came up with the concept of a Magic Object. It is a place holder that can be put on the drawing canvas that is like a template for some not so common objects, but still not uncommon:

After you sized and dragged it, you can remodel it into any shape from the magic object palette. The reason for this idea is that we don't want to create configure dialogs for the objects. The way that Karbon and Inkscape does it now is to have, for instance, a polygon tool that can be configured with number of edges. That is too complicated for the small kids that we want to give this tool to.

When you select an already created object, you can transform it in a number of different ways: its' color, the line type, etc, just like in any drawing program:

The difference with DrawUp is that we have tried to make everything as obvious and transparent as possible. Like this, for instance. Notice the lower right corner, where the fill color is shown as the current property to edit. You won't get much clearer than this:

Finally, here is the New / Open dialog. As before, you can you can create a new drawing from a number of simple templates. And you will of course have a preview of earlier created documents.

And finally some words about the implementation. If you want this to become a reality, please volunteer your time and skill. The current engines of KWord and Karbon are great starting points, and both of these programs will probably be little more than new shells (skins if you like) on top of them.

If you volunteer to help with Kids Office, I can almost guarantee you your 15 minutes of fame. I have been approached by magazine editors who wondered if I was implementing it already and when it would be finished. So don't hesitate or be shy. You can mail me or Danny, and you could go into #koffice on irc where we hang out sometimes.

Usability and Bug Reports

2005-10-12T15:23:00.000-07:00

Well, like a number of other bloggers have already noted, KOffice 1.4.2 is now officially out the door. We have done a lot of fixes, and especially in the support-for-OpenDocument and Karbon departments.

One of the things that we have started to take seriously during the development for 1.4.2 is usability. Usability of a product is a measurement of how easy it is to use. This usually mean applying the Principle of Least Astonishment.

You should provide the user with actions that he or she expects from a certain button or menu item and you should provide the user with the GUI items that he or she expects where he or she expects it. This is not so easy as it might sound. Especially in a highly integrated application suite you need to take several levels of usability into account:

1. You should provide the features that a certain application needs and in a place where the users that have used other similar products expect it. Like, for instance, the style manager in KWord is expected to exist under the Format menu.

2. You should provide the similar actions for all applications in the office suite at the same place. An example of this is that KChart suddenly got a Format menu at all, something that didn't exist before. Previously configuring a chart was under the Chart menu.

3. You should provide compatibility and integration with your surrounding environment, in our case KDE.

Sometimes these 3 levels create conflicting demands that have to be resolved. And sometimes there are many ways to do one thing and maybe no best way.

We think we have covered some distance already on this, but there is still much to do here. So to make it easy for people to show us where we have gone wrong, I created a "Usability" component for all the KOffice applications in our bugzilla. I think that KOffice is first in this regard, which is kind of sad.

Please file usability bugs. I promise that they will be getting a fast review and, if possible, also a fast fix.

At this point I would like to direct my thanks to Alan Horkan who has worked with us on a lot of usability issues. He has previously served as the moderator of the Gnome Usability mailing list, and we are happy to have him on board.

Release of KOffice 1.4.2 Imminent Means Much Work for PR Guy

2005-10-05T14:01:00.000-07:00

After a long delay, it seems that the ill fated release of KOffice 1.4.2 will become a reality after all.

The reason for the long delay (the release was first planned to be two weeks ago) was that a security hole was discovered. It was kind of tricky, and it took two tries to get the fix right. You will hear more of this in the release notes.

The good news is that we had two more weeks of bug fixing, and 1.4.2 will be even more usable than it would have been without the delay. Especially good is that we managed to fix a compatibility bug with Open Office 2.0beta during the latter part of these two extra weeks. That wouldn't have been possible with the original schedule since OO 2.0beta didn't exist at that time (if I remember correctly).

Since this release is pretty substantive for a bug fix release, I want to make a big media splash with it. It's also well timed in relation to the Open Document debate that has been going on and which I wrote about in an earlier blog. So what do I have to do for a release like this? Quite a lot, it turns out:

1. Write release notes and changelog -- of course
2. Ask Kurt Pfeifle (pipitas on irc) to put together a klik package of it.
3. Write an article on the dot.
4. Write an article for slashdot and perhaps other geeky news sites as well.
5. Contact the marketing working group and get their cooperation in trying to make non-geeky news media run the story.
6. Write news item for the KOffice web site.

So why would I want to make this much noice about a simple bug fix release? Well, first of all, I take my job seriously. If I am the PR guy for KOffice, by golly, people will hear about KOffice. Second, I think that our biggest problem right now is that not enough people have heard of it. If more people knew that there is such a thing as KOffice, more people would use it. And third, this is most likely the last release before 1.5, the release that will bring full support for Open Document, using it as the native file format. So we have to make people aware of it now, so that those who need full Open Document support have heard about it before and can start use it once it arrives.

A general rule in marketing is that people like things that feel familiar more than new and unknown things. So my strategy right now is to make KOffice a household word in the Linux and Open Source world. Open Document is the next big thing, and I want all news articles to mention Open Office / Star Office and KOffice when they speak about Open Document.

So far, this is going pretty well according to plan.

KOffice -- Kids Office

2005-09-28T12:45:00.000-07:00

In addition to being active in the development of KOffice, I have also done some work on two other KDE modules -- kdegames, where I am the KReversi maintainer and kde-edu, where I do a lot of small tasks for other people. Most of the time it is simple stuff like bug fixing and code cleaning.

I am also working in a company that provides Linux solutions for, among other customers, schools. This has given me some insight into how school people think, and also what problems they face. I have also talked to a number of Linux packagers that provide special Linux distributions for school use, among them Skole-Linux and another European initiative that currently is working to provide Linux for several thousand schools (that I am not allowed to reveal any details about). These people say that the kde-edu module is one of the immediate reasons why they chose KDE instead of... well, The Other Desktop(tm).

I was in the shower the other day, thinking of a lot of different stuff, when I suddenly got an idea: How about a special edition of KOffice for kids in School? I imagined a much simplified office suite with fewer components (no kexi or kplato for instance), and much fewer features for each program. But not only that: I imagined also a softer and friendlier GUI with rounder corners and a lot of nice colors. This would make it less frightening for the kids to use, and also a lot simpler.

I mentioned this idea to Danny Allen (dannya on irc), who happens to be an artist, and also happens to have a vision for the future of kde-edu. In fact I wanted to model the program(s) after his vision, KidsPlay, and asked him if he could perhaps throw together a quick graphical hack to illustrate my point.

Well, it turns out that Danny liked the idea so much that he went completely into hibernation and disappeared. When he reemerged, not only did I get a quick hack, but I got a complete concept portfolio! So with no further ado, I and Danny Allen give you: KOffice for Schools -- Kids Office

This is the imagined GUI of the word processor. Danny has called it WordUp as a code name. I think he has captured my vision perfectly! Notice the simple and -- really -- intuitive GUI. Notice the lack of menu bar. Instead there are just a few icons that capture the most important functions. This could actually be used by kids age 8-10 to write a small report on some group work they did in class.

Another thing that he used when he designed this is the concept of 3, i.e. max 3 things grouped together: Cut/Copy/Paste, Bold/Italic/Underlined, Sans Serif/Serif/Fancy, Left/Center/Right aligned. You don't need any more! This is perfect! And the notepad metaphore is also perfect.

In addition to all this, he came up with a clever scheme to use color for coding features: green for safe ones, red for dangerous ones and blue for neutral ones.

Note, in the picture above how the paste icon is green when active. Paste is safe, because the pasted text can always be removed without problems. Cut would be dangerous and thus red. Copy would be neutral, i.e. blue.

Here is the complete toolbar for WordUp, as Danny imagines it. I can't say I understand all colors, but it sure looks nice, doesn't it?

He also added a mockup for the New and Open features, where the user can select a number of old documents or templates. I'll let the picture speak for itself:

Now, imagine this together with a shell like the one shown for KidsPlay above and with an integrated drawing application (DrawUp?), and you will have a very, very good office suite for young school kids.

As I said above, kde-edu is right now a big reason to choose KDE in the schools. This could make KOffice another one. And once they are hooked, they will never leave!

It's Final - MA Goes With Open Document

2005-09-23T16:41:00.000-07:00

As you can read on GrokLaw, it is now final that the Commonwealth of Massachusetts will only produce and accept documents in OpenDocument formats.

This is great news for KOffice, the first office suite in the world to announce support for Open Document. True, the support is not complete, but we will do all that is in our power so that the next version 1.5, will have complete support for it in KWord, KSpread, KPresenter, Kivio, Karbon and KChart.

It will be very interesting to see what Microsoft decides to do about this. If it was only Massachusetts themselves that was in the pot, I don't think they would care. However, columnists and bloggers all over the field agree that many, many other states and countries are watching this and preparing to do the same. So the stakes here could be the total domination that Microsoft has had in this area of the IT industry.

Not to let KOffice miss this chance to be in the limelight, I have written an open letter to Alan Yates, the manager who signed the reply from Microsoft about the issue. In that letter I correct a factual error (bad research or lie -- you decide) and also make some nice advertising for KOffice. It will appear on the dot as soon as it is back up, and danimo has promised me that it will also appear on slashdot, osNews and other prestigious news sites.

The Power of Delegation

2005-09-22T18:07:00.000-07:00

One of my tasks as PR guy for KOffice is to see to it that the web site is up-to-date, informative and nice in general. But I am a lazy type, and updating the website by myself would mean work, so that's stupid, right?

What's a poor fellow to do? Delegate of course!

Now, the problem with this is that the KOffice website had fallen into disrepair due to a lack of web maintainer. So delegating to the webmaster was somewhat difficult.

So we have to get a new one. Due to me hanging out with the kde-edu people sometimes, I knew that they have a nice informative website, and I also know their webmaster.

Asking her if she wanted to take care of the KOffice web site didn't seem too straining even for me, so I did. Luckily enough for my ego she accepted without a moments thought so now KOffice has a new webmaster: Anne-Marie Mahfouf.

So here we are with a run-down website, a new eager webmaster and a marvelous product to show off. Anne-Marie has already started to shape things up, and the goal is to have the content revitalized for the 1.4.2 release of KOffice on sunday. Things are looking good, both for me who got my task done without work, and for KOffice who will soon have a website that you can actually use for finding information once again.

Of course, we are also interested in knowing what YOU want to find on the KOffice web, and we want YOU to send mail to us about it.

Last, to show what a really smart person she is, Anne-Marie followed suit immediately and delegated much of her work to Martin Ellis. That's the spirit!

Testing testing...

2005-09-21T09:10:00.000-07:00

My name is Inge Wallin, and I am the new, marketing coordinator -- more commonly known as the "PR guy" -- for the KOffice module. I got this elevated position because I piped up at the KOffice meeting at Akademy saying that "KOFfice needs a PR guy", That should teach me...

(For you who read this at some other place than Planet KDE, let me point you to )

The person you should thank for this blog is Martin Ellis (mart on irc) who relentlessly pestered me to start it. He might soon regret that he ever mentioned it.

The good news is that I will let you know about new and exciting stuff happening in KOffice. The bad news is that I am as opinionated as Aaron Seigo, so you will probably hear a lot about other stuff as well, and you might not like all of it.

After that tirade, I would just like to let you know that KOffice 1.4.2 is on its way out. It will contain a ton of fixes, and a heavily shaped up Karbon. More about that in an upcoming entry.