KOffice 1.3 Beta 2 Released

On June 18th 2003, the KDE Project released the second beta version of KOffice 1.3. It comes with a lot of bugfixes and a couple of new features such as a PDF import filter, new OpenOffice.org filters and more stencils for Kivio. Kexi isn't part of this version nor will it be in the final KOffice 1.3 but it's slated for a stand-alone release later this year and will re-integrated into KOffice in the next major version. Read more in the KOffice 1.3 Beta 2 release notes and in the detailed KOffice 1.3 Beta 2 changelog. Binary packages are expected to be available soon, for now you can only grab the source. Next step is a release candidate planned for 8th August.

Dot Categories: 

Comments

by James Richard Tyrer (not verified)

> Both WordPerfect and WordStar ended up in the hands of Corel ...

And then there was no more WordStar. Which was my point, but thank you for correcting my hazy recollection of the exact history.

>> So, please tell us why compatibility is needed.

> Ah, that's easy. Think of it this way: you have an office full of people who have hard drives full of Microsoft Word documents.

Yes, they have hard drives full of old MicroSoft Word documents.

So, please tell us why they need a MS Word compatible wordprocessor? :-)

To make this clear. In order to show why a compatible wordprocessor is *needed*, you need to show why there is a need to ever open these OLD documents in any wordprocessor.

Keeping old finished documents that will never be edited again in a wordprocessor's native format is a sloppy habit that we should get over.

--
JRT

by Mike Petrie (not verified)

> > Both WordPerfect and WordStar ended up in the hands of Corel ...

> And then there was no more WordStar. Which was my point, but thank
> you for correcting my hazy recollection of the exact history

Actually that's not quite correct. Corel started on a 32-bit version of WordStar for Windows, but abandoned it when Word Perfect became available. WordStar never changed hands and is now owned by either Gores or River Deep - I don't think they're even sure of who owns it. The history, as far as it goes, is on my Web site at http://www.wordstar.org/wordstar/history/history.htm

> So, please tell us why they need a MS Word compatible wordprocessor? :-)

They don't - but they DO, most definately need to be able to view and print, and maybe edit those old MS files.

You'd be surprised at the number of people you contact me and say something along the lines of:

"My dad wrote our family history using WordStar. I don't know
which version, but I want to read those old files into Word.
Can you help me."

Once a document has been written and printed once there's no reason why, in a year's time, or maybe even ten, why someone shouldn't want to print it again. To do this you need a program that can view and print the document. Of course, if every document gets printed to Acrobat format, while that remains a standard, there's no problem - but most documents aren't printed this way.

Any word processor these days MUST support Microsoft's RTF as an absolute minimum. Being able to acurately read and convert Word 2, 6, and 9x documents would also be an imense advantage. If you acn also read - correctly - word perfect and WordStar documents you've increased your potential sales. If in addition you canthen provide a keyboard commend set that replicates Word Perfect or WordStar you've increased your possible market again!

Cheers
Mike

by AC (not verified)

>>So, what I think is needed is the ability to import PDF and PS files<<

Importing PS is almost impossible. PS is a full programming language. While it may be possible to extract the text, there are a million ways to position it.

PDF is a little bit easier, since it is a very restricted subset of the PS programming functionality (with some new layout abilities), but still very hard. Try Google's PDF->HTML rendering capabilities, and see how often it fails.

by Datschge (not verified)

You didn't look at KWord PSF import yet, did you?

by James Richard Tyrer (not verified)

OH. $&#*, the "AC" trolls are back.

Your statement makes no sense. The fact that PS is a full programing language is irrelevant.

It is true that you can only import PS if it is being used to describe a page to be printed -- Penrose tile and affine transform ferns might be a problem. But, if a page can be described in one representation, then it can be converted to a different representation of the same page. How do you think that GhostScript displays stuff on the screen or sends it to the printer?

Perhaps it might even be easier than Micro$oft Word (*.doc) files since PS is fully documented and there is already a code base available OS (GhostScript & PS2Edit).

--
JRT

by not me (not verified)

This AC is not a troll. The fact that PS is a full programming language is *very* relevant. Writing a program that figures out exactly how the text flows on the page is nearly impossible. There are an infinite number of ways of positioning the text, so you can't just figure it out from the code. You have to run the PS and look at the output. But figuring out how the text on a page is positioned and how it flows around objects is a very hard problem, on the order of speech recognition or reading text. The text might be in several columns, right-justified, wrapping around circular objects. Who knows?

by James Richard Tyrer (not verified)

> Writing a program that figures out exactly how the text flows on the page is nearly impossible.

What you are saying is true but irrelevant. IIUC, you are saying that it is impossible for a program to determine information that is not contained in the PostScript file. I believe that that is a tautology.

However it is quite possible for a program to render a PostScript file as an image. We already have one of these you know -- it is called GhostScript.

There already exist programs that import PostScript and render it as an image -- The GIMP for example. WordPerfect will import PS (EPS) and render it as an image.

How do they do this if there is a font in the PostScript file? It is quite simple, they render it. To import it as text, all that is needed is not to render it but to use the same information to import it into the WordProcessor's representation of text.

We already have much of this functionality. Have you ever used: "pstoedit", "ps2ascii" & "pstotext"? If you know the text, its charismatics and where it goes on the page, you can make a WordProcessor file with that information.

--
JRT

by Vajsravana (not verified)

> To import it as text, all that is needed is not to render it but to use the > same information to import it into the WordProcessor's representation of
> text.

This is not "importing". This is OCR.
You see... in many PS files there is no text at all! There is just a description of where some glyphs are to be displayed on the sheet. Some of the glyphs can be text (in the WP sense), some bitmap, some pure vectors.
Extracting from this the "WordProcessor's representation of text" is nothing more or less then OCR, not much different then extracting text from a bitmap or, a better example, a coreldraw file.

by James Richard Tyrer (not verified)

To try to interpret your nonsense:

There are two possibilities:

1. The text is represented as glyphs directly or by a name or number that reference a font (either embedded or not embedded).

2. The text is a graphical representation.

In all cases that I know of, the default output of wordprocessors is #1 although some do offer #2 as an option.

Obviously, if it is #1 then the information can be imported as text, and if it is #2 then it can only be imported as a graphic.

Since you are a PostScript expert, I don't need to tell you that even if the text can not be extracted with: "ps2ascii", the PS file may still be #1.

If you had left an e-mail address, I would have sent you a sample. But, you can do it yourself. Make a document with KWord, print it to a PS file, convert it to PDF with: "ps2pdf" and import the PDF back into KWord (you need the import filter if you don't have 1.3 Beta). This might not work perfectly, but you will get text when you import it.

NOW, try: "ps2ascii" on the PS file. NO text. Open the PS file with KEdit. NO text.

Is it magic?? Or, perhaps you don't know what you are talking about. 8-D

--
JRT

by Vajsravana (not verified)

> There are two possibilities:
>
> 1. The text is represented as glyphs directly or by a name or number that reference a font (either embedded or not embedded).
>
> 2. The text is a graphical representation.

What I meant to say is that, although not common, there are programs which generate postscript as pure vector graphics, keeping the glyphs as vector shapes and discarding the character and the font map that originates the glyphs (you can call it "graphical representation", but this is often used for bitmaps).
You can see a good example of these files if you use hylafax via WHFC and analyse the PS output of various win32 programs... the difference between similar documents printed in slightly different ways is sometimes amusing.

Of course, even if the result is similar when printed or viewed, there is no means of reimporting as text this kind of (otherwise perfectly legitimate) files, but only as a useless vector image.
This discards the idea of using PS as a standard archiving format, at least if you don't limit to programs that generates it "correctly".

> Obviously, if it is #1 then the information can be imported as text, and if it is #2 then it can only be imported as a graphic.

As you know, "as graphic" or "not at all" has exactly the same meaning in this context.

> Since you are a PostScript expert, I don't need to tell you that even if the text can not be extracted with: "ps2ascii", the PS file may still be #1.
>[...]

I usually don't use ps2ascii at all, I know very well how many problems it has, and I too skip directly to PDF instead, when I can.

> Is it magic?? Or, perhaps you don't know what you are talking about. 8-D

Or perhaps you did not even try to understand what I was talking about. :)

by James Richard Tyrer (not verified)

> ... although not common, there are programs which generate postscript as pure vector graphics

So, if it is: "not common" it isn't really relevant to the question, is it?

> This discards the idea of using PS as a standard archiving format.

I didn't say that it should be used as a "standard archiving format", I have, and do, suggest that PDF be uses as a standard format. However, this does not mean that it would not be useful to be able to import PS files directly into your WordProcessor without having to convert them to EPS or PDF first.

> As you know, "as graphic" or "not at all" has exactly the same meaning in this context.

Well, importing them "as graphic" isn't going to get you the text, but this feature -- which is already somewhat available on WordPerfect (it requires EPS) -- still has its uses.

> Or perhaps you did not even try to understand what I was talking about. :)

Yes I did, but I could not tell if you were only talking about PS files that are totally graphic images or the PS files that appear not to contain text when they actually do.

Now that I fully understand, I can state that your reasoning is flawed. Your assertion appears to be that in some (not common) instances you will find a PS file that represents text as a graphic image and that, therefore, the ability to import PS (as text) into a WordProcessor is not a useful feature.

This is to say that because it won't always work that there is no point in having it. This is illogical -- backwards reasoning.

--
JRT

by Arboleya (not verified)

Well, is nearly impossible to know how the text is displayed by code analysis, but is perfectly possible by simulation of the code.

If I am not wrong, all the output in postscript is done by a virtual pen moving on the paper, but all the fonts are stored appart. If is like that, is possible to know where the fonts are being displayed and in which order, just simulating an execution of the program.

by KOffice fan (not verified)

Boy, you sure do bring all the FUD that's been refuted millions of times already.

1) The common standard is still being developed, but something like that doesn't happen overnight. KOffice is moving toward it, but the first step is the development of OOo filters which would smooth the transition. As a start, KOffice changed their file format to use zip, and be more similar to the OOo way of doing it. Changing to a different fileformat is a HUUGE undertaking and KOffice needs volunteers to help it.

2) wvlib is still being developed, but the focus is on getting things right. The current filters work very well for basic elements, and support for complex stuff like embedded objects, tables etc, is coming later. wvlib is shared between Abiword and KOffice, and has nothing to do with OO filters.

If you think that ripping out OpenOffice filters is that easy, why don't you do it. The fact is that it was tried, but was so damn complicated that there would be no point. Shaheed has explained this on the Koffice list many times over. Also, switching to the OOo/Oasis file format is planned for later versions of KOffice. It is not something you can do in a day.

BTW, KOffice document format is based on XML, is documented and transparent. Why are you calling it semi-proprietary?

I really appreciate KOffice for what it is -- a lightweight office that's intuitive, fast, and fun to use. Once the filters improve and there is a common document format, it will be great for most purposes. The only thing KOffice needs is help from coders.

by AC (not verified)

>>The lack of standard file formats in the free software world. There was some talk about an oasis standard based on OpenOffice (which seems to be the most widespread free word processor today), but has anything happened? <<

I guess one of the problem is that a word processor is not a word processor. Unlike any other major word processor, KWord is frame-based. OO's Writer is able to do web forms, which are not supported in KWord. And there will be thousands of things like that...

You could save the world so much trouble by just using the same word processor as your co-workers (when you collaborate) and otherwise use PDF (when the document is done)...

by trynis (not verified)

Yes, you are right. I've been doing my share of import filters to realise that it is more or less impossible to find a common file format. In order to to that, every program would have to match feature by feature, and those features would have to be implemented in pretty much the same way. An example: What is just a visual line in one application may have a semantical meaning in another, while still denoting the same thing. Good luck finding a good way of importing from the first program into the second.

The important thing is not what file format your word processor is using, but what format you distribute your final document in. The word processor's own file format should only be used when writing your document, not when distributing it.

The default file format for an application should IMHO reflect the internal data representation of that program. Otherwise there will be a lot of programming kludges. There will be problems moving documents between versions of that program, but that can easily be solved by either sticking to the same version when writing a document, or by using some upgrade tool (which is much easier to develop than import filters between different applications). If it was possible to have one common file format for all word processors, we might as well only have one word processor.

Use one format when writing your document, and then another (e.g. pdf) when you're finished and want to distribute it.

by Ferdinand (not verified)

What I miss in the discussion is TIME. No office user has time to deal with file formats. What counts today is speed.
Using kmail and receiving M$.doc files is just a painful experience. No way to sell this. So it's not just KOffice which suffers it's the acceptance of KDE-Desktop.
just my 2c
BTW I try to use as much as possible of KDE, but sometimes this compatibility question IS th e issue.
ferdinand

by James Richard Tyrer (not verified)

So, you can start the KM$WordView project. :-)

Maybe that isn't such a bad idea. It is only 3567104 Bytes to reverse engineer -- plus the DLLs if you want it to run on other than x86.

--
JRT

by Ferdinand (not verified)

yes - I know - but I am not a coder as you propably know.

IMHO it's necessary to create awareness among those people capable of coding to focus on key-success-factors of KDE.
- KDEPIM, compatibility and connectivity issues
- KOFFICE, compatibility issues
- KHMTL, rendering issues

I think those working on this programs are well aware of these matters, but I do not see enough "recrutement" and publicity to attract new coders.

Reading the announcements gives the impression, that everything is fine.

Every announcement is the place to point to open jobs!
cu
ferdinand

by Victor R. Ruiz (not verified)

Beta 1 or Beta 2?

by Anonymous (not verified)

I see that Klarälvdalens Datakonsult AB (http://www.klaralvdalens-datakonsult.se/) has finally released KD Chart (http://www.klaralvdalens-datakonsult.se/kdchart/).

Is this version incorporated into this release of KOffice? Based on their comment it is: "It is no coincidence that the current version of the KOffice productivity suite uses our library." If so, is it available as a separate library? I thought that at one time a saw on their website that KD would make this available to the open source community.

by rjw (not verified)

Last time I looked the cvs commits were 8months old.
But it looked fairly easy to rip out into a separate GPLed library.
Hope they will do it as just a module in KDE cvs, then koffice could
import ala admin if they are terrified of dependencies....

I always wonder, I reckon the only dependency moaners must be:
1) Redhat users who don't know about apt for rpm
2) Compile from source monkeys who don't just use gentoo
3) Idiots.

I've never got it, its really unbelievable that after all this time people still
dont just apt-get/emerge/urpmi koffice.

by Fredrik C (not verified)

Koffice is certainly nice but it's still just portable between platforms that has a GPL'd QT version. This only amounts to a fraction of the potential market, thus hindering OS adoption and the freedom for the community. If the Trolls are worried about loosing in-house development revenue then can't they add restrictions for commercial in-house development?

by Datschge (not verified)

"thus hindering (...) the freedom for the community" How so?

by Fredrik C (not verified)

If you feel that being locked to certain platform(*nix) to use a large portion of free software is a good thing then of course the above is false. But I for one think it's great to be able to use Mozilla/OO/Gimp/Scite/Python/wxWindows on every platform I use. As more and more cornerstones of free computing comes from KDE the lack of ports for Win32 keeps me from using it. Even if you think it's a good thing to force people to use Linux I don't like the notion of being ruled by the Trolls when it comes to GPL'd software.

by Fredrik (not verified)

Not a optimal solution more a proof of concept. It strikes me that one of QT's selling points "easy portability" don't apply to the community, and nobody seems to care. Don't bite the hand that feeds you?
As for the FreeBSD remark below, try to understand the topic you reply to (I have nothing against GPL).

by Datschge (not verified)

Well, as someone who is able to pay for a Windows license, an Office license and several other licenses for professional programs you supposedly can't get anywhere else you surely can also spare some cheap money for a toolkit, can't you?

Besides the community aspect should normally be an aspect pro Windows considering their supposed huge user base since more users must mean more developers willing to improve something. And this huge amount of people should be at least able to redo the tiny X11 part of the GPL'ed QT into a working GDI part for Windows, right? Right?

Windows users still can't afford it? Poor poor Windows users...

Yes, you are right, nobody cares, and that's quite fine with me. =p

by Fredrik (not verified)

Well, as someone who is able to pay for a QT license, surely can also spare some cheap money for a OS/Office suite, can't you?

Seriously, my business is trapped in a windows environment, why not make the best of a bad situation.
Openoffice has already helped loose some shackles, when more and more programs are multi os there is less reason not to use a free os. But as of now Koffice is out of the competition for 95% of the user market.

by Datschge (not verified)

The best any business could do to themselves would be forcing themselves to use FOSS and pay the money to developers for programming whatever specifics they need what isn't possible with FOSS yet instead paying the very same money for trapping license contracts. The result would be a true un-trapping instead pretending that Windows was still alright since you paid for it and nevertheless "saved money" by getting all the (still insufficient, since not actively supported) FOSS for free.

If you do not like GPL then use FreeBSD. Koffice and KDE run there as well.

If you do not like GPL then use FreeBSD. Koffice and KDE run there as well.

by Datschge (not verified)

You know it's really funny how you are talking about Trolltech putting restrictions on you while you are obviously happy to continue using Win32 including all the ridiculous restrictions Microsoft puts on you. Please do yourself a favor and read following article about Microsoft's EULA you chose to agree on by using Win32: http://www.cyber.com.au/cyber/about/comparing_the_gpl_to_eula.pdf

For many people not using Windoze is not an option. If you
ever want to get these people off M$ products you have to
give them (and their bosses) a path to follow.

by Datschge (not verified)

There are many paths already. The problem is not that they don't exist but that too few people care to look for them.

by David Fraser (not verified)

The paged linked as "PDF import filter" says nothing about PDF ...
Does this import PDF into KWord?

by me (not verified)

Yes

by kool (not verified)

Great! That would mean interoperability with LyX. Output to pdf from lyx then import into kword. This is the first thing I'll try once I can emerge beta2 on my gentoo system.
Export pdf document from lyx, then decorate the title page in kword.

by ik (not verified)

i think thats not a good idea.. probably the pdf import will loose a lot of the layout. and you loose the latex typesetting offcourse when you import into kword

by Ingo Klöcker (not verified)

You might also want to try LyX -> LaTeX -> KWord.

BTW, the status of the PDF import filter can be found here:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/koffice/filters/kwor...

Unfortunately the status hasn't been updated since 6 months.

by kool (not verified)

TeX import doesn't work on 1.2.1. kword simply gives a message and quits. don't know about 1.3..

by cies (not verified)

What is the problem with using a lot of stuff from OOo?
- that OOo libs should be used then? (instead of KDE libs)
- licening problems?
- ??

KOffice could ditch their own native format and adopt OOo's format as native. Use OOo filters, maybe even use (parts) of OOo's canvas(es). _IF_ this is possible it would help the end-user a lot. The opendesktops can use KOffice the Win-tops can use OOo...

I know this has often been proposed, but i cant remember what was the main reason against it.

-Cies

by fault (not verified)

> KOffice could ditch their own native format and adopt OOo's format as native.

Check out http://www.oasis-open.org/home/index.php. Both OOo, koffice, and abiword/gnumeric people are participating in that in order to create a common and open format to rival MS together.

> Use OOo filters,

Work on this is ongoing.

> I know this has often been proposed, but i cant remember what was the main reason against it.

The rest of what you said (using OOo canvases...) will never likely happen anytime soon. OOo was simply not made with this kind of thing in mind.

by cies (not verified)

> Check out http://www.oasis-open.org/home/index.php.
> Both OOo, koffice, and abiword/gnumeric people are participating in that in order to
> create a common and open format to rival MS together.

Check but could find anything... Anyway the goal "create a common and open format to rival MS together" sound great!

> > Use OOo filters,
> Work on this is ongoing.

cool

by AC (not verified)

>>What is the problem with using a lot of stuff from OOo?
- that OOo libs should be used then? (instead of KDE libs)
...
KOffice could ditch their own native format and adopt OOo's format as native. Use OOo filters, maybe even use (parts) of OOo's canvas(es).
<<

If you want OOo (and not use KDE technology), why don't you use OOo?

by cies (not verified)

> If you want OOo

Yes I want OOo, al least right now. In need M$Office compatibility. Kword only shows the simpelest of M$Word files right.
But I dont like all aspects of OOo, it has several disadvantages -- we all know (slow, big, alien-look).

> (and not use KDE technology)

I like KDE tech, a lot. Maybe i even love it ;-)

> why don't you use OOo?

So currently I am. Hopefully in the furure I'll have some thing slicker ;-)

Note: my post was not a troll, I wanted to know what is the _problem_ for using OOo code. It's both C++. (I think it is the libs that are used)

by AC (not verified)

>>my post was not a troll, I wanted to know what is the _problem_ for using OOo code. <<

It's a completely different program that behaves very differently and has never been designed as a library or something like that. KOffice has its own framework, that is used by most KOffice apps.

by cies (not verified)

> If you want OOo

Yes I want OOo, al least right now. In need M$Office compatibility. Kword only shows the simpelest of M$Word files right.
But I dont like all aspects of OOo, it has several disadvantages -- we all know (slow, big, alien-look).

> (and not use KDE technology)

I like KDE tech, a lot. Maybe i even love it ;-)

> why don't you use OOo?

So currently I am. Hopefully in the furure I'll have some thing slicker ;-)

Note: my post was not a troll, I wanted to know what is the _problem_ for using OOo code. It's both C++. (I _think_ it is the libs that are used)

by Giovanni Masucci (not verified)

What about the koffice icons project?
I heard that everaldo was involved in that project.

by KDE User (not verified)

Nice to see lots of activity with Kivio. Any chance for Kivio import filters for Visio files (*.vsd) ? How about exporting a Kivio screen to pdf?

You should already be able to print Kivio screen to pdf, isn't that sufficient?