The KOffice project today announced the release of KOffice 1.1.1.
KOffice is a free, Open Source, integrated office
suite demonstrating the richness and power of the KDE development environment.
The release, out less than
three months after the long-anticipated KOffice 1.1 hit the KDE ftp
servers, mainly improves performance, printing (particularly in
KWord), and stability.
The announcement
contains links to the source and a number of binary packages, as well as
a summary of the changes. A more
detailed
changelog is available at the
KOffice website. The next release will
likely be released shortly after KDE 3.0, sometime in the first quarter of 2002.
Update Tuesday December 18, @11:42 pm: Timothy Butler wrote in to tell us that
Open for Business is running a mini-review of KOffice, and it's readiness for enterprise deployment.
KOffice 1.1.1 Ships
Dot Categories:
Comments
Right now I'm developing a new filter architecture for KOffice, which allows to use more than one filter for a conversion (I called them "filter chains"). Due to that we will be able to use non-KOffice filters from KOffice. StarOffice, e.g. supports batchmode conversion, which is exactly what we need. However, this stuff is quite tricky to implement -- stay tuned :)
Printing is bad because your machine is not configured right and Qt-based applications have no hint where the fonts might be :-(. Screen based fonts are provided by the fonts server fine, but it cannot download them to the printer - it needs to know the path.
Do it right - at least for me it works perfectly. This has nothing to do with KOffice, all Qt applications including konqueror printing will suffer more-or-less the same. Do you happen to use otherwise-great RedHat's distribution?
According to all of the announcements I read, Krayon was supposed to be included in
this release. However, I downloaded the source and did not see it??
Anyone have any information??
Much appreciation.
Krayon is far too unstable and unfinished to be released.
It has been removed from the tarballs before making them public.
If you - or anyone listening here - feel like contributing to an image editing application for KOffice... please feel free to come and hack Krayon ! ;-)
answer is it possible auto remove duplicate or triplicate posts/replies from the dot? mostly clicking back and submit button once more time will post it (post/reply) again!
answer is it possible auto remove duplicate or triplicate posts/replies from the dot? mostly clicking back and add button once more time will post it (post/reply) again!
Actually, this is an annoying enough problem that I can probably just fix it myself,
if I happen to know the language it's written in. Hey, site admin (sorry, forgot the name),
where is CVS/non-CVS access to the site, and what lang is it in?
The DOT is a Zope site written in Python. Actually, it is a Squishdot application written in Python built on top of Zope. Without knowing what version of Sqish they use, I can't say if they need to either patch the addPosting method or just upgrade to the most recnet version.
Eron
That's too bad, because Python is one of the language I don't know yet, sorry :-\.
However, if someone does know Python, it would just be a matter of putting
this in the article posting code.
----
foreach existing_article (already_posted_article_in_this_thread) {
if (
(existing_article.subject == new_article.subject) &&
(existing_article.author == new_article.author) &&
(existing_article.body == new_article.body)
) dont_post_article;
}
post_article; #Only reaches here if no other article matched.
----
Unless Zope or Python is even weirder then I think it is, that shouldn't be too hard to
code up. There's really no legitamite reason why someone would want to
post two identical messages to the same thread. There's also no reason to display
an error message, as all the poster wanted was to post one message. If the message
was posted at least once, then it worked, and there is no problem.
Very true. Maybe if we find out from Dre what version of Squish he and Nav are using we can check for a patch. What Squish currently does is convert the time using "str(int(ZopeTime))" that returns an ID of the seconds since the Epoch. So you could theoretically post the same piece every second without it being checked for duplicates. The most recent version may fix this, however.
Eron
it doesn't look like there are any new or updated export import filters for Koffice 1.1.1 Any information what to expect? Decent .rtf export/import and what about .xls?
I always use Koffice for all my work I'm sure I never have to export to MS like letters etc. I'd like to use it for my specification documents that go to MS-Users as well (especially that is where SO's hunger for resources hurts most)
Conrad
Why don't we just focus on a filter to import and export SO docs.
If we had that we could just use the Star Office filters to export and import to any format that SO supports.
Imports would be easy:
Word(or whatever SO supports) -> SO -> KOffice
So would exports
KOffice -> SO -> Any file format that Star Office Exports.
Could someone please explain why we have to have our own filters and keep
reinventing the wheel, when Sun obviously has a large interest in having
SO be completely compatible with MS Office? I'm confused
well - it should be easier. The problem is said to be the cryptic MS formats. Why not spy with SO (Openoffice) to write a decent rtf filter. Has anybody tried this.
Conrad
spy???
What I'm saying is make sure you can import and export to SO. Once you can do that you can just take advantage of their filters, which work quite well.
All of this would be transparent to the user. If they try to open a .doc file, then KOffice would use the SO filter to import it as an SO document, then KOffice would convert that SO document to a kwd doc (all of this is transparent, behind the scenes). When you go to save the document as a .doc file, KOffice converts it to SO format, and then to .doc using the SO filter (again behind the scenes).
It seems to me that if you just get the import/export SO capabilities you would be pretty much set. Rather than SO, Abiword, and KOffice each doing their own attempt at .doc import/export filters, take advantage of the work that SO has done. Why re-invent the wheel? Plus the SO format is open, XML, anyone can read it rather than some binary closed format.
Actually, this is being worked on right now. Some of the results are already in KO CVS/will be in KO 1.2. However, we are directly porting the SO filters. It'd not terribly trivial, but much easier than reversing Microsoft formats.
sounds pretty cool!
but what happens when openoffice updates their filters? will the whoel thing then have to be done again, or is it just a few clicks and scripts that have to be run?
in other words: will koffice's filters automatically improve as the openoffice-flters get better?
We plan to use the binary filters. If the OO filters get better we can use the new ones, even without a recompile needed. So much for the plans... ;)
I think this is a great idea.
StarOffice/OpenOffice has done a tremendous amount of work getting their in/out filters to a very strong point. I think having native filters is cool, but it means that there is going to be a while before we can get them as good as the filters in StarOffice/OpenOffice. The hard work is done. If KWord had a really good set of StarOffice/OpenOffice in/out filters, it could easily make use of the EXSISTING filters created for StarOffice/OpenOffice. Then effort could be spent working on one really good strong set of filters (ANYTHING to/from StarOffice/OpenOffice) that would benefit users of both StarOffice/OpenOffice and KWord and anthing else that can read/write StarOffice/OpenOffice format.
I guess the major advantage to going native, is that once it matures, some things may translate better from KWord to MSWord than KWord to StarOffice/OpenOffice to MSWord, but I don't know any of the products well enough to purpose what kind of things would fit this category.
Does anyone know a site where we can share/get KWord-Templates? This would help a lot.
Try the templates at http://users.skynet.be/bk369046/template.htm under Ktemplate.I found I had to install in my home directory under .kde2/share/apps/kword/templates (I'm using SuSE 7.3)
Great!!! Thank You.
Also see the sourceforge link = http://sourceforge.net/projects/ktemplate
I recently tried out KWrite and was simply amazed at how far you folks have come. Great work!! Sure it's got some issues, but what software doesn't?
There will always be those idiots who complain about this and that, without even giving things a fair shake.. I say fuck em. They're not important.
you mean kword? ;o
Kword is really coming on nicely. I haven't fully tested 1.1.1 yet but still the progress is gratifying. Kword is much more than wordpad, even though some features are not yet implemented.
I can remember only a short time ago when kword was completely unusable, now it is good for many tasks. I'm really looking forward to 1.2
StarOffice has alot of advatages at the moment but kword has nifty features that SO does not and even openoffice is quite demanding on system resources.
Hi,
Wow, first of all, I'd like to thank you guyz for the work on KOffice. Of course it's KWord that got my attention. I fiddled around with it, and was really surprised by the absence of crashs. So, even I'm not a developer, sometimes I get hold of a crash and can fix it, but here I didn't get the opportunity! God bless...
Is there some documentation around? I have a big question regarding the insertion of picture-files. I'd like to insert a .eps-file in a KWord-document, but the file is inserted as bitmap, and thus pretty nasty to look at! If you could point me to a documentation I will gladly look up the answer there. But I didn't find any.
greets and kudos (where does this word come from?)
Ineiti
Usually, at least in other packages, the bitmap is used for display on screen, and the actual postscript is used during printing. How does the document look when the device is printed?
Could someone let me know if this isn't the way that kword works.
I'll be looking forward to trying kword again sometime soon - I'm just being spoiled with frame at the moment, and I didn't want to risk a thesis in kword when I started...
Cheers
Will
--
Hi,
no, it doesn't show up nicely in the printed version. On the screen it looks quite nice (not with 400% though), but as soon as I print it, it's not readable anymore. And, yes, the original .eps is readable!
Greets
ineiti
kudos comes from the greek word for glory: kydos.
Ok, I am Greek, but this is the first time I have ever heard of this word. Glory in greek is "thoksa" (tho- as in "though"). Could you please tell me where you got your information from? Maybe it is a long-forgotten word from ancient greek.
This is a bit off topic; or maybe it's the i18 thing!
Anyway, I know nothing about modern Greek, but Koine Greek (the language of the New Testament) has the word 'doxa' for glory, which finds its way into English in words such as 'doxology'.
Oh, and KDE + KOffice in phenomenal, which is another English word from Greek, and it's mega, etc...
it isn't modern greek. i dug this link up for you on google:
http://www.bartleby.com/61/27/K0112700.html
Hi all,
A while ago Kernel Cousin KDE #13 - http://dot.kde.org/992464961/ mentioned that someone was working on Avery label templates for KWord.
Other than the screenshots listed there's no additional information about the templates. I've looked around but have not been able to find any download or availability information. Does anyone know when these templates are going to be released?
perhaps an email to the fellow putting the templates together would be a good way to get an answer to your question?
Thanks for the awesome work in KOffice!
However, there is a problem and I'd be glad if someone could give me a hint:
My KDE locale is iso8859-1, German. I want to use KOffice to edit ancient Hebrew texts, which is iso 8859-9 afaik. I can do that, but when I try to print I only see ??? characters, which probably indicates that there is some problem with Unicode at the printing.
Is this my fault? Any help is appreciated.
Select the Hebrew text, go to Format / Font, and
in the font dialog, select the iso-8859-9 encoding,
to apply it to the selected text. Although this changes
nothing on screen, usually, it helps printing such text.
Such workarounds will not be needed anymore with Qt 3.
A source diff can be found at http://www.hmallett.co.uk/diffs/
Hywel