Kastle 2003: KOffice Developers' Meeting Report

Quite a few KOffice developers took the opportunity to meet during the Kastle event in Nové Hrady, and particularly to discuss the future of
KOffice after the next major release (KOffice 1.3 slated for the end of September 2003). A summary of the topics discussed follows.

Topics discussed
File format
We will switch to the OASIS
(OpenOffice.org) file format for all the major applications. This has many advantages:

  • file format shared with the OpenOffice.org suite, we don't have to
    reinvent the wheel
  • we'll be able to drop our OOo import filters and use the export filters
    as a compatibility layer for older KOffice versions documents
  • we can actively participate in the standard file format creation in the
    the case of Kexi and Kugar which are applications that don't currently
    exist in OOo

This is also a good opportunity to switch the names of our MIME types to the
vnd.kde... naming scheme and to drop our KOffice-specific file
extensions. It's again the users who will benefit from this step, e.g. on
Windows it will be possible to open files created with a KOffice application
using the OpenOffice.org suite.

KOffice libraries
We intend to break the binary compatibility soon after the 1.3 release and take
this opportunity to clean up and refactor kofficecore and
kofficeui libraries.

The next KOffice version will depend on Qt 4.0 which will have a better rich text engine
that we will reuse. Our text library (kotext) will be redesigned as
a thin wrapper around this rich text engine and will provide KOffice-specific
functionality only. (David)

The scripting library (koscript), currently used in
KSpread
only, will be rewritten from scratch to provide a new light-weight formula parser.
(Werner, Ariya Hidayat)

Kexi
It is still unknown whether Kexi
will be released separately later this year. Otherwise it will definitely
be part of the next KOffice version. The problem is that Kexi's core API
isn't stable enough yet so it makes no sense to do a separate Kexi release
which would depend on already obsolete KOffice libraries. (Lucijan)

KChart
Big thanks go to Kalle who finally imported KDAB improvements and fixes into
KOffice CVS.

Scripting, automation
We decided to use kjsembed
engine as a foundation for the new KOffice internal
scripting engine. It will allow users to write their own wizards, interactive
forms or scripts using JavaScript and Qt designer forms. Work is also being
done on KDevelop side which will provide an IDE these tasks. (Zack)

Spellchecking
Current plans are either to rewrite the current API after KOffice 1.3 and KDE
3.2 releases or to reuse the newly born Enchant
backend neutral spell checking engine. This architecture will have 3 layers:
different backends, a core library and dialogs. (Zack, Laurent Montel)

Common canvas library
The plan is to have a common canvas class that KOffice applications could
reuse for their own drawing needs. Currently there exist different
implementations in
Karbon14,
KPresenter and
KSvg.
The goal is to have a common library so that also other applications
can draw various shapes without the overhead of KParts embedding.
(Rob, Lukas, David)

Ongoing work
The KOffice developers are currently busy fixing various issues so that we
can ship a stable release candidate at the end of this month.

  • fix spell checking (Zack, David)
  • checking that language property is being used for different portions of
    text (David)
  • fix the character (font) dialog in KWord and KPresenter (David, Lukas)
  • continue KPresenter bug hunting (Lukas)
  • discussions about future drawing objects and common canvas functionality
    (see above)
  • discussion on table-frameset design (KWord developers)
  • Kexi hacking (Lucijan, Joseph, Holger)

Developers present at the meeting
Lukáš Tinkl (release manager, KPresenter)
David Faure (KWord, libraries)
Werner Trobin (libraries, filters)
Zack Rusin (filters, spell checking)
Lucijan Busch (Kexi)
Joseph Wenninger (Kexi, Kugar)
Alexander Dymo (Kugar)
Andrea Rizzi (KFormula)
Thomas Zander (KWord)
Rob Buis (Karbon14)
Holger Schroeder (Kexi)

Dot Categories: 

Comments

by James Richard Tyrer (not verified)

> Most windows users don't know how to make PDFs

I would go farther than that, I would say that most Windows users don't know what a file format is. If they did, they would have probably sent you an RTF file.

But, that doesn't mean that products should be designed based on user stupidity. It is my belief that Linux should not be dumbed down to accomodate stupid users because such users have no reason to switch to Linux.

--
JRT

by anon (not verified)

> It is my belief that Linux should not be dumbed down to accomodate stupid users because such users have no reason to switch to Linux.

Ok, but the world doesn't work like that. I'd get fired if I refused to take MS Office formats and work with them, and demanded non-company-standard file formats. Remember that Linux users represent less than 1 or 2 percent of the desktop.

by James Richard Tyrer (not verified)

I think that you missed the point.

I presume that you mean that at work you use MS Office as your office suite. This is not the issue since if your company used WordPerfect Office, you would be using WPO file formats. If you used Foo-Bar Office, you would be using FBO file formats, etc.

The question is not about documents you are working on, it is about *completed* documents. Specifically about the bad habit of sending people completed documents in DOC files rather than RTF files (as I think MS originally intended) or converting to PDFs.

--
JRT

by yg (not verified)

> Much of what: http://www.mind.lu/~yg/office.html says is simply wrong.

That is your opinion.

> What does it mean that you have to "deal with Microsoft Office (MSO) files"?
> Does this mean that you have to be able to open them in an application so that
> you can edit them, or does it mean that you just have to read them somehow?

Edit them (which includes saving without screwing them) and print them.

> This is an important distinction.

Not in business. Ask your CIO if he would give green light for a new Office suite that can only read MSO files... dunno if he would like it...

> And the printer example is even dumber. Hasn't he heard of PDF.

sure I have.
I work for a service company, and when a customer sends me a document I am not
really in the best position to tell him "buddy, I need a pdf".
Coz I would be the only 1 to tell him "I cannot handle M$ Office files".
All the other IT companies he deals with don't bother him.
And you know sometimes I get documents I have to edit and send back.

I wrote this document http://www.mind.lu/~yg/office.html with users in mind.

by James Richard Tyrer (not verified)

> Edit them (which includes saving without screwing them) and print them.

IIUC, people from outside your business, send you DOC files and you have to edit them. Is this the norm, or just a small percentage of the cases.

Printing isn't an issue, a viewer can print if you have the fonts.

> Ask your CIO if he would give green light for a new Office suite that can
> only read MSO files... dunno if he would like it.

Not "read" but rather view them.

My CIO understands that it is a LARGE security problem to exchange DOC files, and I use MS WordViewer to view them.

Actually, HOWEVER, it is *reading* DOC files which is the problem, many wordprocessors can write perfect DOC files (because they don't use the cryptic "features").

> And you know sometimes I get documents I have to edit and send back.

Edit, or just mark up?

What I am saying -- my point -- is that a viewer, like MS's viewer that could view and print (this should include print to PDF and FAX) DOC files would solve many of the issues without the problems of an import filter.

--
JRT

by Nicolas Goutte (not verified)

Reading MS Word file is not really a problem. The problem is the automatically executed macros. KWord has not any macro inside documents. So no need to worry about that!

(That is the same reason why some people prefer RTF over native MS Word documents.)

Have a nice day!

by Nicolas Goutte (not verified)

Sorry but where do you see that a file viewer would be easier than an import filter? For both you have to "dissect" the file format.

Have a nice day!

by James Richard Tyrer (not verified)

The disection is done by a library:

http://wvware.sourceforge.net/

To view the document all you need is sufficent information to "paint" the screen. You do not need any information about the document's structure.

--
JRT

by Nicolas Goutte (not verified)

And how can you paint without browsing in the document structure? (I suppose that you want a little more than just the raw text.)

Have a nice day!

by Philippe Fremy (not verified)

KOffice plans to switch to Qt4. But KDE has not planned this yet, as far as I know. This means that future version of KOffice will be independant of KDE ?

Also, beware that such huge rewrites have killed more than one project. Gnome has been stopped during two years just to switch to Gnome 2 and the same situation occured during the KDE1 KDE2 switch.

by capit. igloo (not verified)

> "Also, beware that such huge rewrites have killed more than one project. Gnome has been stopped during two years just to switch to Gnome 2 and the same situation occured during the KDE1 KDE2 switch."

But not for KDE3...

by Nicolas GOUTTE (not verified)

I do not thing that it means that KOffice is going its own way. It only menas that Koffice 1.4 will be delayed until KDE 4.0 is out. And I do not think that it is a waste of time, as there is enough bugs and wishes for KOffice.

I do not really understand your comment about the huge re-write. In any case, we do not have any Qt4 (alpha, beta...) right now. So we will have to do the file format switch first and then the Qt4 switch. I still see an opening for a KOffice 1.4 for KDE 3.x if there is really a need.

Have a nice day!

by Alex (not verified)

Sure a rewrite might take a while but that's where innovation really comes from, luckily Linux does not have sucha big user base so we can still afford to break compatibility. One of Microsoft's greatest weaknesses IMO is that they can't break compatibility any time soon.

Also, IMO the advanatages gained from the KDE 1->2 rewrite or GNOME 1->2 rewrite far out weigh the consequences.

Please break compatibiltity if it yilds large advantages. KDE 4 is not a point release, you're meant to break compatibiltiy. but please don't break compatibility between X.X and X.X.X releases. However, KDE 4 will be a X release and we need to let 3.x live longer anyway so the time required to make a rewrite will not be a problem.

by Rayiner Hashem (not verified)

KDE 4.x will *not* be a rewrite. KDE has kept the same basic architecture since 2.x, and IMHO its a good one. It should be good for at least a couple of more full releases. Stuff that breaks compatibility might be useful, but a full rewrite would just be a waste of perfectly great code. Plus, a large amount of what KDE needs to work on now is not the internal technology (except for maybe replacing aRts!) but UI polish.

I know it would involve some work getting these filters into a reasonably independent state from OOo, but at least this way you would have both an import and an export filter. I'm sure that the OOo and Abiword people would be interested in this.
Also since all of the important office suites for the desktop would be using the same filter code, it can only improve the filter.
My 0.02 c

CPH

by Nicolas GOUTTE (not verified)

Sorry, but I doubt that it will be the same code. All three word processors use very different libraries. (See also the many discussions on the koffice mailing list about why we do not take OO's code.)

However what can be done is to create libraries to ease the programming of filters. That what has been done for the MS Word import.

Have a nice day!

by Holger Schroeder (not verified)

Hi,

the switch to the ooo fileformat offers us the possibility to use openoffice as a nice import filter for ms office files. switching our internal file format is a lot of work, but trying to separate the openoffice filters out of openoffice is only time-consuming, and not probale to work out at all.

openoffice is able to be scripted, and transforming a ms .doc file into a .sxw file is as simple as taking a template document containing a transform-script, executing openoffice with that script file from the command line.

after that you can simply open that sxw file, either with an openoffice import filter, or in the future you will be able to simply open it as it is then the native format.

(any people interested in hacking on this are very appreciated :-)

Holger

I'm sure everyone would love to do this, but the OOo MSOffice filters are _very_ linked to OOo specific code, and not only that, it's a plain mess to work with (not that it isn't a wonderful piece of technology, but after years of work, and I can imagine only a few people working on it, it's gotten really obfuscated) :)

I am not sure what this forum is for (KDE?) but I do care about openoffice filters.
Just for your information, there is a little application using openoffice macros to convert files and fired with a command line through openoffice. If you want to check this try at http://oooconv.free.fr/ . It is quite fast (the time for openoffice to open then convert, save and close), but it would be faster if someone can extract the filters code. I do not know if the related Ooo filters code is bound to Ooo specific code and I do not really want to jump into openoffice source code to verify this. Anon, Have you got any links which explain this very precisely or did you verify it yourself? Thanks for replying.

Maiko

Can you compare OpenOffice with MSOffice ?

by defaced (not verified)

Did anyone notice it yet? http://www.kde.org takes me to a page which protests against software patents.

by Dieter Nützel (not verified)

I only get "wire frame" printings and my nephew is not very excited...;-)

Try printig preview.

Thanks for GREAT work!

-Dieter

by James Richard Tyrer (not verified)

I see nothing about fixing the 'bassakwards' WYSI-not-WYG printing in KWord.

Is this a priority? Is work being done on it?

I realize that part of the problem is Qt::qpsprinter, but this has to work!

A wordprocessor that doesn't print correctly is useless for most purposes.

As was discussed on , the current system tries to duplicate on paper what is displayed on the screen (it FAILS, but even if it succeded it would not be good) rather than making a very good (but not perfect) lower resolution +/- one pixel representation on the screen of (exactly) what will appear on the paper.

--
JRT

by Nicolas Goutte (not verified)

I suppose that this is a reason of the switch of KOffice 1.4 to Qt 4.

Have a nice day!

by James Richard Tyrer (not verified)

No. It isn't necessary to switch to Qt-4 to rewrite the internal representation of the "painted" image.

--
JRT

by Nicolas Goutte (not verified)

I have not written that it is necessary.

I have just meant that if KoText can be designed on top of Qt4 instead of being a replacement of the corresponding classes, then it would be easier to fix bugs and to use Qt's improvements (like Indian scripts.)

Have a nice day!

by Christoph (not verified)

I have benn using koffice(eg kword and kspread) for some time now for really small things.

kspread is really useful and works well. thumbs up.

kword is very nice for simple "word" documents, but the table support is so bead it makes my head split every time i use it :

- You never know what your table looks like if you save your document and load it again.
-cells are lost
-contents of cells is gone
-you cannot select a table *
-you cannot move a table around *
-you cannot resize a table *
*=these points work somehow, but its so bad no one will ever be able to use kword tables ;-) you really have to rethink the way tables are handled in kword.

Mfg Christoph

by MandrakeUser (not verified)
by a (not verified)

This is excelent news!!! I always wished KOffice was compatible with OpenOffice.

Congratulations to the KOffice team for this decision!!!

by mlitty (not verified)

Yes. THis is a great move toward a common file format, a popular standard, and dare I say, a unified front against ... well, ya know, theMS.

by Alex (not verified)

Could somebody change te default KDE webpage-style.
The Yellow-style looks much better.

by Praedor (not verified)

Without a really useful vector drawing app the office suite is incomplete. Karbon14 simply isn't an appropriate replacement for kontour. Users of drawing apps have simple expectations and karbon14 fails to meet the most basic: the ability to draw simple lines, polylines, arrows (lines with arrow ends), etc. Such an ability is in ALL other drawing apps on the planet: OODraw, SODraw, Illustrator, CorelDraw, KONTOUR, Freehand, MacDraw, etc, etc. The odd man out here is Karbon14 which has replaced lines with sinewaves and nautilus shells (!?). What POSSIBLE use outside some very specialized need are these "lines"? Useless for 90%+ of those doing drawings for publications, books, or presentations.
Kontour was nearly there. It had almost everything necessary except a few more export/import filters and stability. Karbon14, nice in theory, is nearly useless in practice. You will NOT win officesuite converts by providing some bizarro drawing app that is totally at odds, interface and function-wise, from every single other professional drawing app out there. Either karbon14 needs a lot of work (someone forgot simple lines?) or it is simply not designed to be a widely useful drawing app and should not be part of the koffice suite.

by anon (not verified)

Agreed... I think karbon is the start of something pretty good, but doesn't handle basic shit.

by lion_fui (not verified)

What about KPlato? Is it dead?

by Anthony (not verified)

I didn't see any mention of Kivio, and I surely hope this doesn't mean it is going away. I am a big user of Visio, and would love to get away from it just for doing network diagrams. I have tried Kivio in the past (even purchased some extra templates) but it was just not stable enough for my needs. I don't want to use the TheKompany version if the free version can really move forward. Is anyone still working on this project ? (and don't simply tell me I should, I am not much of a programmer really, and unfortunately my time to do Linux stuff is very limited).

by Anonymous (not verified)

For the simple reason that the Kivio maintainer, yes there is a new and active one, didn't attend the meeting.