Things are getting closer. The KOffice team is proud to announce the release candidate of KOffice 1.5. With lots of good feedback from the users of beta 1 and beta 2, the release candidate is better than ever. We now invite the user community for the final round of testing of KOffice 1.5 before before the suite is finally released. Read the full announcement, the changelog, download the release, and give it some real world testing for us!
In this release, the OASIS OpenDocument support is improved even more, especially in KChart. It's still not perfect, but we have improved interoperability with OpenOffice.org a lot. Krita has gotten faster and more stable and KFormula has a new maintainer that has really come up to speed quickly. And that's just the highlights: across the board, we have improved all applications, making them better and more polished.
Comments
I've just uploaded Debian packages to unstable.
They should be available tonight, in the meantime you can get them from:
http://people.debian.org/~isaac/koffice/
I'll try to get packages for Sarge ASAP to have up-to-date kliks.
Best regards :)
Great, great, great!
I'll do my best to have kliks available half an hour after you announced your Sarge packages then.... :-)
Cheers, Kurt
[ and thanks for all your hard packaging work -- making the kliks
on that bases is really easy now, and much less of a job ]
Oh, and I forgot to ask one thing: what about the "MS Access Import Driver", described here:
http://www.kexi-project.org/wiki/wikiview/index.php?MDBDriver#2._Download
Would it be possible to provide *.deb packages for this too? (I must be blind if they are already out there, somewhere; I didn't find any).
I'll give them a try after I finish with Sarge packages.
Yes! Please do... the mdb drivers would be great to have!
Hats off to all of the Koffice developers for moving us closer to what I'm sure will be a great release. There is just one thing keeping me from using Koffice (mostly Kword) on a daily basis instead of OpenOffice. For some reason or another whenever I use Kword it always seems to leave an irregular amount of space between letters. Sometimes letters are mashed together without enough space between them and other times there is a noticeable gap between letters. I'm sure I'm not using the proper nomenclature to explain this, but surely someone knows what I am talking about. Are we to expect any changes with respect to this issue in this release? If not, are there plans to address this in the future. I really would like to use Kword instead of OpenOffice Writer on a daily basis, but I do a lot of printing and this issue comes up a lot for me. In any event, thanks again for all the hard work!
Adam York
Hmmm. Wasn't that planned to be fixed? I can't check right now, but I thought it would was being worked on. Ohh, I think it might be something that requires Qt4, so you'll see it fixed in KDE4.
I read a very very long time ago, that there was some flag in XFree86 which if set at compile time would include a good font-kerning in it, but because of some licensing problems it was off by default. Then I read something about Trolltech telling they would include real font-kerning in Qt4.
I Hope it will get better, because that is something I think Linux still lacks, it has become a little better with those anti-aliasing, but still I have the idea that under Windows or MacOSX the fonts look generally better...
Don't come with well those fonts are better, because I'm just importing the windows fonts, and it still looks better under Windows...
Hmmm. Well I guess KDE4 with Qt4 won't be that far away. I'm really looking forward to fonts looking better in Koffice.
To make your post a bit more precise ;-)
Professional TrueType fonts (like those from Microsoft or Adobe) usually contain additional information on how to optimize the look of the
letters at various font-sizes (this is called 'hinting'). This additional information comes inside the font files in form of a small application (bytecode). Some but not all commands of this bytecode are patented. Thats why FreeType (the free font renderer usually used on Linux) is usually compiled with support for these commands turned off in many distributions to avoid
legal repercussions.
Not all fonts use these commands but most professional ones do. So if FreeType encounters such a command it can skip this command (but this usually yields unusable, ugly results) or totally ignore the complete hinting information including the known commands. This is what usually happens. To prevent the fonts from looking extremely awful, FreeType can "invent" its own hinting code automatically (called auto-hinting) which is not as good as the real deal but much better than no hinting at all.
So, if you have problems with fonts you might want to try recompiling
FreeType with patented bytecode support turned on. This means removing
the "/*" and "*/" from this line in the file ftoption.h
/* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER */
from the source-code of FreeType and recompiling the whole thing.
Described in detail here (just googled it for Mandrake):
http://convexhull.com/mandrake_fonts.html
Search for TT_CONFIG_OPTION_BYTECODE_INTERPRETER and your distro on
the web if you want to know more.
Caveat emptor: This will of course only improve TrueType fonts and only
those which use these commands (like Arial, Tahoma, Verdana). Type-1 fonts do not contain such information at all so there's nothing to improve there.
Usually this makes only sense for screen fonts. On the printer resolution
is high enough for hinting to be mostly irrelevant. Decide for yourself if you want to go through all those hassles. Modern open-source fonts (like DejaVu) yield results which are at least equivalent if not better than for exampel Microsoft Tahoma which has been specially designed for screen legibility.
Thanks Martin. I'll certainly try this out.
Adam
Mandrake/iva doesn't support this hinting thing? I thought they did, since it is a French distribution (they don't have to fear patents, and, in fact, include support for MP3/DVD and all out of box) and fonts in it look much better than in Suse. So, fonts could be rendered even better?
> I thought they did, since it is a French distribution (they don't have to fear patents,...
How do come to this idea? Patents exist in Europe as well and the patent holders in case of mp3 are french and german. Mandriva will pay for the mp3 license.
I was obviously referring to software patents. Their holders might be french and german, but they are only filled on countries that have them (USA, Australia, etc).
When you refer to software patents, you shouldn't have mentioned mp3. And no: In Europe there are already thousands of software licenses filed and (questionably if legally) granted by the european patent office. It's just nearly impossible to enforce them, since there's no common european patent law.
This is all quite true but it isn't relevant for printing. Hinting is for the low resolution screen display.
For printing the fonts should be spaced without hinting and Qt 3.x is not able to do this.
Yeah. The I've been trying to use KWord to, but have been unable to because of the font spacing issue. I did some reading and also figured it must be the freetype glyph hinting thing. So I downloaded the freetype source deb (I'm using the unstable Debian release) planning on enabling it, and discovered it already was.
As the freetype changelog says (or as you can deduce from debian/rules and debian/patches/030-bytecode-interpreter.diff in the source package):
freetype (2.1.2-10) unstable; urgency=low
* Turning back on the bytecode interpreter. Too tired to care now. May turn it off again when Xft2 and fontconfig are in Debian.
It seems from the source package that the only other Debian specific things are a backwards compatibility patch (adding back in some dropped API), some consistency checks (underflow and overflow checks for BDF glyphs), and an X related rpath linking option. So, unless I've missed something, I'm thinking it is a QT/KWord thing.
In fact, from James post, it almost sounds like I should just disable hinting (I have a high resolution display) and everything will be fine. Maybe I'll give that a go.
Okay tried recompiling without the bytecode interpreter. It changes the output (both on the screen and on the printer) for sure. Some parts are better and some parts are worse. For example, if you use the Times New Roman font at 12pt, a printout of the word "away" will have excess space between the 'w' and the 'a' with the Debian stock freetype. If you recompile it freetype without the bytecode engine this goes away, however, the word "serious" acquires a space between the 'o' and the 'u'.
After digging into it a bit, I was left unclear over whether the the full bytecode interpreter is enabled by default (due to the inclusion of the autohinter). For completeness, I tried a version compiled with the bytecode enabled (i.e., TT_CONFIG_OPTION_BYTECODE_INTERPRETER defined) and the autohinter disabled (i.e., TT_CONFIG_OPTION_UNPATENTED_HINTING undefined). I couldn't tell any difference over the stock version (i.e., both defined).
Hmmm... I have a good set of fonts (Microsoft's "web core" fonts - Arial, Times, Courier New etc) and I tunned up autohinting in my freetype. The combination of both gives me an almost perfect rendering and spacing of letters on the screen, and on (rare) printouts)
Have you tried using good fonts?
Yes I've tried a variety of fonts and it's still never looked as good as in OO. I'll try some others though.
Adam
How do you mean by tunning up autohinting? Were or how can you do that?
The font problems in KWord and KPresenter will indeed be fixed when we move to Qt4. And today I spotted the first relevant commit in svn trunk :-). In any case, you can mitigate the problem by using good quality fonts (Monotype or Adobe) and a high resolution (that means, lots of dpi, not just
lots of pixels) screen.
I've noticed the problem with OO2 and Abiword, too, by the way. Only Scribus seems immune at the moment.
Font problems in Abiword are most often due to using Zoom to page width rather than Zoom to an even number like 100%. There may be other issues too but like I said most font complaints about Abiword go away when users change their zoom level.
The same is true to a certain extent for KWord. In any case -- I wouldn't work with anything but zoom to page width in any word processor. I'm so happy that Thomas added that zoom level to KWord :-).
I have only seen this problem with MS fonts. Other fonts like Nimbus work just fine both on screen and in print.
1) I created an odp file with OOo impress. When I tried to open it with kpresenter, it's a mess. The title with a font 36 in OOo does have a font 11 and are not anymore center for example. The strange thing is that the effect is not systematic but depend on the slide.
2) I tried to do the opposite and save a file create with kpresenter in odp and open it with OOo2. The first thing I saw is that the bullet are missing. I didn't push to much the test after it. It's a shame but opendocument between the two most pro-eminent open-source office suite gave to very different result. In the state it's not possible (in my opinion) to tell that the ODT format is an exchange format.
3) I tried to do a bug report but I don't know where...
Your softwares are very cool, the critisim above are only to help to have the best office suite :). Thanks again.
Nicolas
ps: I'm using package from kubuntu
For reporting bugs please go here:
http://bugs.kde.org
Bye
Alex
> It's a shame but opendocument between the two most pro-eminent
> open-source office suite gave to very different result.
> In the state it's not possible (in my opinion) to tell that
> the ODT format is an exchange format.
I'd like to emphasise here that problems exchanging OpenDocument documents between KOffice and OO.org usually indicates a bug in software at the moment. The OpenDocument specification itself is a very good thing.
OpenDocument documents may fail to load correctly for a variety of reasons:
- Architectural issues. For example the way KSpread stores formatting information currently scales very poorly. When OpenOffice.org produces spreadsheets, it assumes that assigning a particular format to a large area of otherwise empty cells is 'cheap' in terms of memory and time when loading - not true in KSpread. This should be fixed in the 2.0 release.
- Bugs in KOffice or OpenOffice. This is probably the biggest cause. KOffice is probably the worst offender since this is the first release with serious OpenDocument support. Other developers certainly ran into OpenOffice bugs as well on the road to 1.5 (When developing OpenOffice, there weren't really any other packages to test its output against, so OO.org may load and save a document correctly even if the saved content is wrong)
- Missing features in KOffice. It is a younger office suite and doesn't have all the features that OO.org has (eg. KSpread doesn't support multiple text formats in a single cell)
- Ambiguities in the specification. This is the most problematic when it happens, but I don't think there have been many cases of this so far.
The problems concerning OpenDocument support are in some ways similar to achieving compatibility between web browsers when dealing with HTML/CSS. Although both formats are well defined, open and stable, there is a lot of work required to support all aspects of them and even small flaws can produce big visual changes.
The good news is that a large set of test documents are being compiled at the moment so in the future we should have a good set of reference documents to test against.
Do file->new and file->open still take you to the same place in the same widget? It's a small thing, but that redundancy really annoys me, especially since its smallness makes it likely to be ignored.
http://osnews.com/permalink.php?news_id=13975&comment_id=104819 <- how to reproduce my gripe.
This is a bug indeed; I'll take a look.
I must have missed the report when you reported it to http://bugs.kde.org :)
You have to do a good lot of clicks just to append a row to a table. MS Office / Open Office allow you to do this with single "Tab" press.
You have to do yet bigger lot of clicks to insert / append several rows.
Has it been really so hard to apply a little bit of thinking to details so simple and trivial?
Is it really so hard to dive into the code and come up with a patch? We know the current table implementation is very limited in reliability, in usability, and in many other respects. Doing a new table implementation is hard work, much harder than you seem to appreciate. Suggestions, help with testing, that's all welcome. Sneering is not.
Unfortunately, I've got no spare time to dive into the code.
"Doing a new table implementation is hard work..." - sorry, I've got only one answer for that, no sneering intended - it should have been done with usability and convenience in mind from the very beginning. As for now, KWord is confined to "quick and simple" documents. For them, it's excellent choice - lightweight, simple, well-integrated with KDE. For more advanced missions - my personal choice is OpenOffice.
A classic example of the importance of design.
'Design twice, code once'