The KOffice team is proud to announce the first beta of KOffice 2.0. The goal of this release is to gather feedback from both users and developers on the new UI and underlying infrastructure. This will allow us to release a usable 2.0 release, demonstrating our vision for the future of the digital office to a larger audience and attract new contributions both in terms of code and ideas for improvements. Read on for more information or see the announcement and download it from the release notes.
This is the first beta release of KOffice 2.0, and the first version we encourage users to download and try out. After a very long development cycle KOffice is now in feature freeze. The development team will from now on shift focus from new features to bug fixes until 2.0 is released.
The release team has decided that the following applications are mature enough to be part of 2.0:
- KWord, Word processor
- KSpread, Spreadsheet calculator
- KPresenter, Presentation manager
- KPlato, Project management software
- Karbon, Vector graphics editor
- Krita, Raster graphics editor
The chart application KChart is available as a shape plugin, which means that charts are available in all the KOffice applications in an integrated manner.
Highlights of KOffice 2.0
KOffice 2 will be a much more flexible application suite than KOffice 1 ever was. The integration between the components is much stronger, with the revolutionary Flake Shapes as the central concept. A Flake Shape can be as simple as a square or a circle or as complex as a chart or a music score.
With Flake, any KOffice application can handle any shape. For instance, KWord can embed bitmap graphics, Krita can embed vector graphics and Karbon can embed charts. This flexibility does not only give KOffice unprecedented integration, but also allows new applications to be created very easily. Such applications could target special user groups such as children or certain professions.
Unified Look and Feel
All the applications of KOffice have a new GUI layout better suited to today's wider screens. The GUI consists of a workspace and a sidebar where tools can dock. Any tool can be ripped off to create its own window and later be redocked for full flexibility. The users setup preferences are of course saved and reused the next time that KOffice is started.
Platform Independence
All of KOffice is available on Linux with KDE or GNOME, Windows and Macintosh. Solaris will follow shortly and we expect builds for other Unix versions to become available soon after the final release. Since KOffice builds on Qt and the KDE libraries, all applications integrate well with the respective platforms and will take on the native look and feel.
Native Support for OpenDocument
KOffice uses the OpenDocument Format as its native format. This will guarantee interoperation with many other Office packages such as OpenOffice.org and MS Office. The KOffice team has representatives on the OASIS technical committee for ODF and has been a strong participant in the process of shaping ODF since its inception.
Comments
The credit for this cuddly giraffe drawing goes to the OpenClipArt artist 'lemmling'. His profile can be found under http://www.openclipart.org/media/people/lemmling . Thank you!
One cannot have enough cuddly giraffes. Very cute indeed ;-).
hi,
i didn't hear anything about linuxmce in the past time. is there already someone working on it to get it into shape? the dev-ml isn't saying anything about it. i haven't found any roadmap or something like that...
thanks!
this is very off-topic, but you're right...
huge announcement:
http://video.google.com/videoplay?docid=2176025602905109829&ei=_MjbSNGmM...
but it seems nothing has happened...is it dead?
besides, linuxmce's UI is extremely ugly. xbmc is *way* better than linuxmce.
Look at it!!!
http://img140.imageshack.us/img140/377/aeonstarkhomecg1.jpg
http://img140.imageshack.us/img140/8530/aeonstarkhomemovedcx3.jpg
BEAUTIFUL!
http://www.aeonproject.com/
but even the standard skin is way sexier than linuxmce.
looks like linuxmce was the wrong choice. I suggest going xbmc!
http://xbmc.org/blog/2008/09/18/xbmc-atlantis-beta-1-released-now-servin...
thanks for reading... :)
I am one of the developers of LinuxMCE.
Yes, we agree that the Basic skin currently in use on our Orbiter is not very pretty, we do have the capability for looking a lot better, we just need interested artists to work with us for making a complete replacement for Basic, for not only one target, but 7 different device targets.
We are far superior to XBMC and other "Media Center" solutions, precisely because we are NOT a media center, but a whole house smart platform, and this whole house philosophy extends to each and every display surface in the house, not only TVs and monitors, but:
* Tablets
* PDAs
* Cell Phones
* Touch Screens on IP Phones
and more.
Can XBMC do this? no. not really.
So instead of people trying to scream at us for it being ugly, why don't interested parties come to LinuxMCE, watch the HADesigner screencasts, and help us make a new look?
That would be fantastic.
-Thom
Hey!
I'm atm trying to get a media center pc with linuxmce up and running for my brother.. but well.. he HATES that interface and that's the reason he's looking for something else... it feels REALLY slow and looks just plain ugly... well.. we seem to agree on that point.. also it's sometimes badly structured and challenging to use (you get tons of fullscreen messages during install that new hardware was plugged in .. good idea but it should be grouped/...)
No I'm no artist .. I'm just trying to evaluate the problem... as far as I've heard the HADesigner is pretty powerful but it's horrible to work with it .. doesn't make it really attractive for designers who are (at least the designers I know) always a bit shy about software which looks really complex...
So.. what has happend to the plans about UI3 .. there were disussions about it long time ago but it seemed like there was no decision (flash, ...) and so nothing happend.. or am I wrong here?
This post shouldn't be offending .. I'm just trying to find out how the current state of development is
Best regards,
Bernhard
first of all: thanks for notice our questions, Thom.
imho the design is another thing; i just wanted to know whether anyone has picked linuxmce-code up and ported it to qt4/plasma/whatever. once it is in kde, i'm pretty sure that the kde-artists are going to have a look at it ;)
greets
Actually, I can control XBMC from my computer, phone, tablet, etc. because of python extensions. I don't see why I would want to however.
Congrats to all the KOffice devs! You do great work.
Thank you to the Devs for their commitment to KOffice and all the work that went into this beta release!
Keep up the good work, it is really appreciated!
Err, I really hope the fonts in KWord will look different from that screenshot...
What's wrong with the letterspacing?
Just look at the line next to the blue man that starts with "Ut wisi enim..."
You can hardly tell where the words start!
This looks like a fuck-up caused by built-in window$ font rendering routines. I know Qt strives for native look&feel, but... was it necessary to do this with the document view? Isn't it sufficient to use native widgets for the interface, and render the document with some other font rendering engine that doesn't suck as much?
If you have antialiased fonts activated, it will indeed look just like you expect it to. This screenshot was taken on a windows machine that has font hinting/antialiasing disabled. I agree, it was not a very good choice.
Fonts without antialiasing are much better for my eyes.
Except only Asus EEE PC witn subpixel rendering.
Again, letterspacing problems are caused by trying to show on your computer screen what will get out of your printer. Your screen is probably around 100 dpi which means that fonts need to get hinted. Hinting means that the width of each glyph will be adjusted to the screen pixels, so it'll be different than the exact glyph width. And that means that at certain points the error becomes one pixel, which means the placement of the next glyph has to be adjusted to not let the error become bigger and bigger, and that results in either big or too narrow gaps between two letters. Your printer doesn't have that issue since it's dpi is much greater.
The other option would be to turn off all hinting, and then you get a lot of fuzziness, but no spacing problems.
No, this is simply because KOffice strives to show real-sizes. So 100% means an amount of pixels that is equal to a real world size. I.e. an A4 page in KWord is really A4 size on your screen. The slight zoom (0.981 on my laptop) causes rounding errors in Qt to be very visible.
Will work on fixing.
A good start would be to read http://www.antigrain.com/research/font_rasterization/index.html
Thanks for your work!
Hmm, I'm quite sure that what I was saying is the real cause. If it shows nice at 100% on your screen I think that's just luck. Move to another screen with a different dpi and it should look worse then (since measured in pixels 100% on your screen would be 98% on another for example)...
Trust me, I know what I'm talking about when it comes to Qt and fonts :)
ps. never said it shows correctly on my screen.
OK, I read your reply again, and looks like I misread it. But now I see you've basically said the same I did in my first reply, only you didn't go into details how it "exactly" happens... :-)
If what I said really was wrong in some way then please tell me what exactly is wrong.
The screenshot: "koffice2-beta-windows.png" is certainly not the way that I want WYSIWYG to be displayed. The glyphs appear to be hinted since they are aligned with the screen pixels. I do not want WYSIWYG to use hinted glyphs.
I trust that you are knowledgeable. However, the issue exists that: 1) Hinted at screen resolution & 2}) WYSIWYG are mutually exclusive.
Hinted at screen resolution normally makes the lines longer. So, it you are going to use hinted glyphs with the same metrics as WYSIWYG, you are going to have spacing issues like the screenshot. Whatever the cause, there needs to be a way to fix this problem.
Funny as far as I remember, there have been fonts issue in *every* promotion screencapture of KOffice..
That's too bad: there have been lots of efforts spent on it, yet they're (to some extent) wasted by the usual font rendering ugliness..
i have to agree: if i had to choose between almost unreadable fonts (try to identify all the whitespaces in the screenshot) or a non-exact size, i'd choose the non-exact size, especially if that's what other word processors do too.
btw, just out of curiosity: how come this problem is so hard to solve (eg not by just using a greater precision in the calculations) ? It seems to me that moving some chars 1 px to the left / right would make the text readable, so it is not yet the "half a pixel" problem here.. I'm not implying here that i think it is a simple problem (i know problems sometimes are much harder than they look at first sight), i'm just a bit curious ... Also i guess scribus avoids these problems because they are using a whole different mechanism of font rendering ?
Has someone built them? (for ubuntu 8.04.1 with kde 4.1.x/3.5.10)
I'd be interested to try this, but I wouldn't go so far as to build it myself...
/Simon
Yes, see the announcement on kubuntu.org:
http://www.kubuntu.org/news/koffice-2-beta
That's for Intrepid Ibex, doesn't work for me in Hardy. :(
Sorry, i'll reply to myself.
From Kubuntu's site:
Packages for Kubuntu Hardy are being worked on, but could still take some time.
Sorry.
Does anybody know a good link to download koffice-1.9.98.tar.bz2 ?
You can get the source tarball here:
http://download.kde.org/download.php?url=unstable/koffice-1.9.98.0/src/
My favorite part of koffice is Krita it an application that looks and feels really useful. I have not use it alot, but compare to krita 1.X it is capable of so much more. A goof job by all the Krita developers
thanks really for mentioning the obvious, koffice works for linux either you use gnome or ( insert you favorite GDE)
mmmm, if only you have used more original names, except krita, honestly how we pronounce koffice, kword ?
Dander, kplato rocks ( grrrr, i hope someday we will get cost account assigned to resources )
thanks
"honestly how we pronounce koffice, kword ?"
Kay-office and kay-word. Sort of like eye-life and eye-photo. Isn't this complaint played out yet?
Pronunciation is that, but I was always wondering why the word processor component had a name so strikingly similar to the most used word processor from a very large company. The similarities between the two programs are dwindling - a new name for KWord would be brilliant. KType? KText? KProcessor?
"word processor" => "KWord". Logical. Send complaints to that other company for using a generic name as a trademark.
Note the capitalization, they help with pronunciation.
Its "Krita" and "Kivio"
vs.
"KWord", "KPresenter"
The first 2 are just single words, the second two are basically a normal word with a K plastered in front. We decided on those names many many years ago, no way to change them now :)
The problem with Knames (or iNames, Gnames etc.) is quite simple really. Suppose that you have a menu that lists your apps. If they all start with a K, it means that you need to look at the SECOND letter and beyond to determine which app is which.
Take Krunner for example. I use it to launch my apps. With Knames, I need to type more letters for it to determine what app I'm trying to launch, since lots and lots of apps start with a "K".
With more varied naming, the names would be more spread out to different letters, making it easier to select them from a list or launch from Krunner.
> Take Krunner for example. I use it to launch my apps. With Knames, I need to type more letters for it to determine what app I'm trying to launch, since lots and lots of apps start with a "K".
That's a bad example. KRunner will also match "onq" to "Konqueror", or "document viewer" to "Okular". So, it will be sufficient to type "pres" if you want to launch "KPresenter".
Try to simply skip typing the K the next time. I do share your sentiment about the names in menu's, although my default menu doesn't even have the names in there anymore. It is also a bit annoying if you need to edit configuration files: every file there starts with a k...
> thanks really for mentioning the obvious, koffice works for linux either you use gnome or ( insert you favorite GDE)
I think the author is may be talking about QGtkStyle (http://labs.trolltech.com/page/Projects/Styles/GtkStyle. KOffice runs w/o standing out like a sore thumb natively on GNOME.
Yes, I know I've brought this up before.
Two things that kept me away from kword were (1) bad table support; I have never got it right in kword and (2) ugly print-out; a document good looking on screen would be ugly when printed. Have these things improved in kword ?
except for these two annoyances I should say the kword and koffice in general are really great.
asok
Print outs have gotten excellent. This is the main reason I picked up my participation again for KOffice2. KOffice makes PDF creation a first-row-citizen and the PDFs created at least in KWord look great!
Any text problems you see on screen are not present in the PDF.
The tables situation has not improved, we have recognized the problem though and are working on a good way to do tables. I have great ideas on how to do this and work much better using the text layout itself (meaning it will work in all koffice apps).
Unfortunately that will not make it into 2.0 so you will see that tables have gotten slightly worse. I personally think that unless we have something that actually works its not worth hacking together.
There are ~50Mb binary ArchLinux packages, built from KDE SVN trunk every day, for Koffice available below. ArchLinux binary packages are basically tarballs that can be extracted from / (root) on any linux distro, but, some library dependencies could be different. Could be useful for some folks to try Koffice out.
http://pkg.eth-os.org/kde-svn/i686/
http://pkg.eth-os.org/kde-svn/x86_64/
or will that have to wait for the 2.1 release?
i ask because in theory the ODF 1.2 spec is due out around now........
Yes and no. It will support some parts of 1.2, although I can't really define exactly which parts. But no, it will not support the full 1.2 spec, which is actually quite big.
But then on the other hand, no office suite supports all of ODF 1.2.
many thanks for the update.
But that is not the reason to not try to implent all 1.2 features as fast as possible ;-)
Isn't it the reason why we have the standards so we can be sure it is supported? ;-))
We surely do want to support as much of ODF as possible, but at the same time you have to keep in mind that we have only limited resources. Once we have the time and a reasonable enough idea of how to implement a certain feature, it will get into KOffice as soon as we're done with it.
The first thing I have missed in kword is a simple option to change the font. So, I'd suggest to enable the toolbar option by default.
IMHO 80% use only this options:
- load a file
- save a file
- change the font
- change the font size
- bold style
IMHO 15% use also
- change page layout
- add a image
- change the line spacing
- add a list
If I can do this tasks very easy, the program is well for me! :)
You get a context menu when right-clicking the text. Select the entry "Font..." and there you go :-)
I personally use other buttons like 'Italic' or 'Align Block/Justify' quite often, and usually change the font type only one time per document, so I'm satisfied with how things are now.
Hey guys: Does anyone knows if KSpread would have Dynamic Tables with Data Base support . Excel have his Pivot Table, and OpenOffice his Data Pilot (IMHO OpenOffice Data Pilot sucks compared to the "other", i don't know if OO Pivot Table is too slow because of Java or why.).
But that functionality isn't available in KSpread, would KSpread have this functionality?