This Month in SVN for October looks at KOffice development. "While much of the rest of KDE is in feature freeze preparing for the imminent release of KDE 3.5, KOffice developers are starting to work hard for their 1.5 release, scheduled for between KDE 3.5 and KDE 4. This release will be able to be used with KDE 3x and Qt 3x, and will have a great deal of improvements over the current stable version." Topics covered include accessibility improvements, Krita one step closer to world domination and how you can help out.

Krita's progress is incredible amazing. I recall having used it with the KDE 3.0 times and I was nowhere good enough for anything. But nowadays it looks like a fully replaced application to me. I bet that together with the release of KDE 4, Krita will become as powerful as Photoshop and quite a look a like too. Easier for people getting their work going.

Though I wish that with KDE 4 there would be some sort of KDE core library for doing graphic stuff with functions that can be shared by other applications as well. Like image viewer, like basic paint functions in spreadsheets or docwriters and for Krita itself. I say this because I really like to not depend on ImageMagick.

> Krita will become as powerful as Photoshop and quite a look a like too.

According to the developers they aim for a Painter-alike application, not Photoshop, which is lightyears ahead to Gimp. And Krita doesn't compare to Gimp feature-wise yet. Also it's even slower than Gimp, which is a lot slower than Photoshop. Regarding usability Krita is better than it's gnomish cousin, though.

I'd say nice ideas, on track, a lot to do, but definitely not an alternative for proffesional software yet.

Fortunately, we have CMYK -- in fact, Krita has CMYK, Grayscale and RGB in 8 and 16 bit per channel, and we have RGB in 16 and 32 bit float. The fact that Krita can separate a 16 bit RGB image into 16 bit grayscale images for C, M, Y and K channels alone is a very professional feature.

And I see that Adrian Page just has committed optional OpenGL support for Krita, which should speed things up for some people :-).

agreed. trying to *work* in cmyk space is atrocious in GIMP, as is working in LAB. People who say "oh but it has CMYK" are deluding themselves. Unfortuantely, if you want to blame anyone for GIMP not having good alternate colorspace support, you need to blame Adobe, not the GIMP crew. It's Adobe's anti-competitive patents that prevent GIMP from offering CMYK support.

Having said all that, I love the GIMP, and it's rare that I absolutely have to work in CMYK and/or LAB colorspace on my Linux box at home. At work, I have Photoshop.

Sure: The selection tools are very basic, Gimp sucks with files >= a few dozen MB since the filters and especially Python and Script-Fu are damn slow - even weird results and crashes I could notice. Overall Photoshop is _a_lot_ faster even in a VMware session, I guess Adobe has just far more experience with in memory image data handling and algorithms. The user interface is still a bad joke - even though it has been improved with 2.2.x. E.g. there are still needlessly a thousand dialogs popping up (this hampers your workflow and isn't the right place for additional information) for text handling, sheering,... I noticed that people have huge problems getting gimp-print working and it didn't worked for me either.

So if you're making only a bit web graphics and your time isn't worth the buck, Gimp is a really nice application, but beyond that: NO!

GIMP is more than good enough for the average non-artist who needs to do something, and good enough for most hobbyist artists who want to do something. Professionsal artists need more power, and should pay the $700.

The GIMP is great, but building expectations beyond what it is does nothing helpfor for free software or the GIMP.

We are much better off in the long run selling GIMP/KRITA as a intersting tool that is worth installing because it is free, and might be good enough. Undersell it, and let the application sell itself to those who won't hit the limits.

Such rants do not change the fact that the GIMP lacks critical features required for the printing industry and many other facets of professional work. It's a lovely program and I use it at home for digital photos and a little web design. Even though I prefer to use KDE/Linux for all tasks, I must face facts though that if a program has not implemented features one's entire business depends apon then it's simply not suited for that purpose.

This is not an insult to the GIMP - it's just not designed to be that professional photoshop-killer application. Neither is using KOffice to generate PDF's a replacement for professional desktop publishing tools. Is this an insult to the intelligence of KOffice developers? I have a high personal regard and respect for them. I'm sure they'd agree with me that there are professional products that for very certain and specific use cases are actually more suited to the task at hand than KOffice is.

I do not think that there is a lack of intelligence on developing such real great tools like the gimp or krita, but it must be allowed to talk about other products, even if they are closed source and even if they are better!

I hope that somebody can finally solve the ongoing font kerning problems in KOffice. The character spacing in printing previews and real prints is so broken that it looks plain ugly. I have seen this problem on many up-to-date Linux configurations, while others do not experience the problem.

IIUC, this problem is caused by Qt, therefore there are two possible fixes:

Qt-4 might be able to fix this but I no longer see anything about WYSIWYG on the trolltec web page.

A new painter and PostScript driver (perhaps borrowed from Scribus or OO).

Specifically, the Qt-3 painter uses fonts hinted to the screen resolution and then tries to print with that spacing (which it doesn't appear to get right either). To be clear, Qt-3 will not do WYSIWYG -- it can not display using either the UN-hinted font metrics or the font metrics hinted at the _printer_ resolution. Both of these (in addition to the screen resolution) are needed for a properly functioning office suite. In addition, to use the printer resolution, KPrint is going to need support for PPD files (it needs it anyhow).

I don't know what use is there of an office document if it
cannot be printed properly. None of the Koffice components print
documents any good. The pdfs created from koffice components
are ugly when printed. I think the developers should get the
basics such as printing right before proceeding any further

I guess it actually depends on the kind of fonts you are using. With msttcorefonts package I was getting problems similar to what you guys describe. But I was able to get quite decent printing from KWord using Nimbus fonts, as well as other non-MS and non-TTF fonts. It took me a few hours (not to say days) to finally figure out a way to unscrew the debian defoma pile of doggie doo-doo, but in the end it is working pretty well, on screen, on print preview, and on paper.

Again, this is a Qt issue. When TrueType fonts are embedded in a PS file (to make a PDF, first a PS file is created and then converted to a PDF by the GhostScript PDFWriter) they are converted to Type42 fonts. In OO, the Sun converter is used to convert the TrueType font to a Type42 outline font, but Qt converts them to a type42 bit mapped font.

The solution to this problem is to configure Qt (run "qtconfig" and in the "Printer" tab, uncheck "Enable Font embedding") to NOT embed the fonts. Then GhostScript will do the embedding and it also embeds as Type42 outline fonts. Note that for this to work that GhostScript must find the font files -- your system must be correctly setup.

So, there are two places where the code to fix this could be borrowed, OO and GhostScript.

I'm a big enthusiast of the whole OpenDocument stuff, but sometime ago I've read two articles on Newsforge that made me wonder that we are far from having FULL compatibility among Office suites. The articles are:

I don't know if there's a solution being developed yet, does anybody know if there are any plans to solve these problems inside OASIS? Maybe standardizing on OpenFormula ( http://sourceforge.net/projects/openformula ) for formulas and Python for macros (do not even know if it possible) could help with the full compatibility among Office suites without the need to reinvent the wheel...

Just a day after this article was published, Adrian Page included a new feature in Krita: OpenGL-support.

From the kde-commits mailing list:

===
SVN commit 475547 by page:

Add support for displaying images using OpenGL, taking advantage of hardware acceleration if available. This also opens up the world of shaders, for GPU accelerated rendering algorithms and general purpose computation, the first of which should be real-time adjustment of exposure for high dynamic range images.

OpenGL can be enabled/disabled in the settings dialog and it defaults to off for now.
===