The KOffice team is proud to announce the 1.6.0 release of its office suite. This release is mostly a feature release of Krita and Kexi, but also contains major enhancements to the OpenDocument and MathML support of KFormula and new scripting functionality. This version also contains a vastly improved version of KPlato, our project planning application. Download packages for Kubuntu, SuSE or you can try before you install with the KOffice 1.6 live CD.
The 1.6 release is intended mainly as a feature release for the two fastest developed components: Krita and Kexi. However, other components are being actively developed too, with astonishing results. The highlights of this release are:
- Krita Becomes Usable for Professional Image Work
Krita and its maintainer Boudewijn Rempt won the aKademy Award for "Best Application" at this year's KDE conference in Dublin. With features such as magnetic selection, effect layers, colour model independence and full scriptability, it has risen to become what is probably the best free image editing program today. - Lots of New Features in Kexi
Kexi, the desktop database application competing with MS Access, is the other application in KOffice that is already the best of its kind. Kexi has received over 270 improvements since KOffice 1.5. With this release, Kexi gains such features as the ability to handle images, compact the database, automatic datatype recognition and Kross scripting tools. - KFormula Implements OpenDocument and MathML
The formula editor of KOffice now supports OpenDocument and MathML and uses it as its default file format. It also surpasses the equivalent component in OpenOffice.org, scoring 70% on the W3C MathML test suite compared to 22% for OpenOffice.org Formula. We see this as one example where the work to provide a very well-structured codebase of KOffice pays off to create a superior support for the existing standard. - Scripting Support in KSpread, Krita and Kexi
KOffice 1.6 brings scripting to a new level with scripting functionality in KSpread, Krita and Kexi. Scripting is provided through the cross-language script bridge Kross, which enables KOffice to be scripted in Python and Ruby with possible future extensions through Javascript and Java. With this release, KOffice also introduces command-line scripting where, for example, spreadsheet documents can be automatically manipulated with scripts to create many new usecases.
This will be the last non-bugfix release until version 2.0, which will build on Qt 4 and KDE 4 technology. For more information, see the full announcement, the detailed release notes page, and the complete list
of changes.
Comments
I'd like to know whether this fixes the formatting bugs in KWord that has actually stopped me from using it. It's just things like suddenly rearranging text in the wrong way, not being able to position things properly etc. I've had to use AbiWord and OO.o which have their own bugs and are slower.
Anyway, it's good to see the new release and the new features - Krita is the best free image editor along with GIMP, and Kexi is IMHO better than OOo Base.
No, it probably doesn't: KWord had some crash fixes and a bit of OpenDocument compliance work done on it, but no major surgery on the text layout engine -- which is what it would take to fix things like the infamous table bugs or the printing metrics. However, those should all be fixed in 2.0, which will use the newer and much more capable Qt 4 text layout engine. Check out Thomas Zander's weblog st http://www.kdedevelopers.org/blog/91/ to see some screenshoty goodness... or you can build KDE 4 and koffice 2.0 to see for yourself. More help -- or just more eyes trying out the code and reporting bugs while they're still new and easy to fix -- is always appreciated! ^_^
Whatever else - has anyone noticed the speed with which the applications open now? Nigh-on instantaneous. Amazing, thank you.
Simply great. Krita is the _first_ OpenSource app supporting CMYK. The importance of this cant be stressed enough. Now I can use Krita for editing print images already. For web editing I still resort to GIMP though Krita is coming along nicely. Imagine one day I could open and edit images via KIO directly on a webserver via FISH or FTP. Amazing. My windows colleagues cant do that. Right now the only thing for web editing I'm really missing in Krita is a true Color-to-alpha filter like in GIMP and a better canvas resize dialog where I can select if the existing image is centered to the left, right, bottom, or top on the new canvas when I resize say a 10x10 canvas to a 16x16 canvas. In GIMP I can freely drag around the image on the new surface before clicking OK. I'm really missing this here. Anyway, thanks for the LOT of work they put already into Krita!! It certainly has not gone unnoticed for me.
Just wonder will krita support raw format of each digital camera?
It already does -- using dcraw for now. For 2.0, I'll likely switch to Hubert Figuire's libopenraw.
Do you mean that you can directly import the Bayer CFA image or that you simply use an external library to convert to a interpolated pixel image.
We don't use a library right now; we exit to use dcraw, and that generates an 8 or 16 bit rgba image.
So, there is no support for raw images.
There is exactly as much support for raw images as any other application that can load raw images has. There are no applications that work directly on the unchanged data from a raw camera; every application needs to convert it first. And actually, most application use dcraw or dcraw-derived code for that, even Adobe applications. Some applications, like Lightzone may do that transparently; others make it explicit. But there is no application where, when you load a raw image, the colorpicker gives you the uninterpolated data, for instance.
> There is exactly as much support for raw images as any other application that
> can load raw images has. There are no applications that work directly on the
> unchanged data from a raw camera.
What do those programs that come with the cameras do?
No, there is raw support. Maybe you did not understand correctly or Boudewijn Rempt was unclear.
You can open Raw files the same way as Jpeg or PNG files. When opening Raw files an additional dialog (with preview) opens where you can adjust white point, contrast,...
Of course Krita can use 16 bit colors with raw files.
Just download Krita and test yourself.
If krita uses it's own raw processing or a lib or an external dcraw should not matter als long as it works. And it works.
It may just be a semantics question, but if an external program produces an RGBA image which is _derived_ from the RAW image then it does not load the RAW data directly and you can not use Krita to tweak how the RAW image is converted into an RGB image. I can't really see how this is an improvement over a JPEG image unless this is the only way to get a lossless image (if the camera doesn't offer Huffman JPEG).
Clearly, the term 'support' isn't being used in the same way as it is when you say that Krita supports CMYK.
Adobe says that PhotoShop supports DNG image files but I have not used it and don't know exactly how it works. I don't know if PS can do the same things as the proprietary software that ships with cameras. But, if it doesn't, they what is the advantage of the DNG format?
To gain the full advantage of using DNG (or other RAW image) files, you need an application which supports interactive manipulation of the actual RAW data.
Just because you can not see the solution doesn't mean it doesn't work.
As an engineer; you should first test the setup before commenting on it.
I'm really not inclined to buy a copy of Adobe Shop and Windows just to try it.
I am looking for an Open Source solution to working with DNG (and other RAW) image formats.
As I presume you know, images using the Bayer CFA system have 1/2 of the pixels for Green, 1/4 of the pixels for Red, and 1/4 of the pixels for Blue. This means that 2/3 of the color information is missing and must be recovered by some method.
http://en.wikipedia.org/wiki/Bayer_filter
So converting a RAW file to a full RGB image does not use a fixed algorithm like decompressing a PNG does. There are various methods for filling in the missing pixel values and various paramaters for the values for antialias filters, etc..
Therefore, what a serious photographer needs is a photo application that directly supports DNG (or other RAW) format.
There is _no_ open source application that uses an in-memory representation of the original raw data when applying filters and such. Every open source application uses dcraw; recently, however, digikam and Hubert Figuiere have been working on replacing dcraw with a library to load the raw data. As far as I can tell, the data is still represented in memory as rgb pixels. What you say you need, you actually do not need at all.
It is, theoretically, possible to write a Krita colorspace plugin that sees the components of the raw data as a single pixel and that renders to an rgb pixel for use on screen; I'm not sure how useful or pointless that would be. But, apart from the sophisticated interpolation methods that make up so much of dcraw's source code and that are a major reason for opening raw images take quite a bit of time, it wouldn't be hard to do. It would be cool do -- but as I said, possibly quite pointless.
Still -- the raw image is the negative. You don't work on the negative; you work on a representation of a negative. In real-life photography, that representation is caused by the rays of the lamp going through the negative: it's those rays that you modify with filters, and the chemical processes in the emulsion layer on the paper that you modify with nasty chemicals.
In digital photography, you work on a rendered version of the raw data, and apply your filters. You do not lose important possibilities that way, because you can create another initial exposure by converting it using other options a second time.
Probably should have mentioned that I am a serious photographer.
So, yes, I do want the same digital capabilities that professionals have available in proprietary programs.
I have also suffered through DSP in engineering college so I understand the limitations of interpolation -- interpolation can make aliasing worse. I would find it interesting to find out if deconvolution would actually work better than interpolation -- theory indicates that it would but it might not be practical. Obviously, deconvolution could only be done on a PC due to the amount of computation required.
It is also probable that using homomorphic deconvolution to remove noise would work better on the RAW camera data before the missing chroma data was restored by whatever method since this can only amplify the noise.
professional programs don't work different! only the algorithms used may be better(raw converting isn't easy, as you noted).
many professional photographers convert their raw images in a special application.
even apples aperture, that does every other operation dynamically without destroying the image, converts raw-images on import and stores it in rgb format in its database (though it also keeps a copy of the original in raw).
but thats just how destructable image processing works. thats how photoshop works. non-destructable workflow just didn't land in the 2d world yet ;).
maybe thats a point that will be addressed in 2.0(hint :P)? they at leased should kick out the painting tools that work directly on the image, and use stroke paths instead. making filters only work as adjustment layers should be easy =).
In case this wasn't clear, after you import a raw image file, it is going to be in an RGB layer but will only have the CFA pixels which actually exist.
Exactly which operations would be appropriate on the CFA data are something which I would have to consider.
Obviously, operations on the tonal range and tonal curves (with defaults supplied by the DNG file) would be needed. You need to do something about dead pixels. Then there is noise reduction and the operations needed to convert to a full pixel image. There are various ways to interpolate, and this requires an antialias filter (which I would like to see adjustable). Deconvolution uses only an FFT filter to do everything -- an FFT filter can implement a perfect brick wall filter. There is also the Moire issue.
But, there would be a point where you had produced a full pixel RGB image and would no longer work on the CFA image which could be discarded.
Dont forget Scribus, a QT based page layout app. It has had CMYK support for a few years and has most of the prepress abilities that designers would want.
We published a few pages of a news paper using it (it has very nice python automation abilities) and we never had any pdf problems.
check www.scribus.net
How can you compare an app that can create CMYK images (by painting or converting to it) with an app that can simply handle it.
The point of the poster is very true, Krita is the first Free app that is able to do CMYK (in all sorts of bitdepths even).
In case you didn't know, Scribus is a professional desktop publishing application. It does all sorts of black magic related to colour profiles and the like.
Sure. It can handle CMYK. Which I said. But how you can honestly say that its in the same league is beyond me.
They have completely different purposes, and are hard to compare. Scribus is a great program that I actually use WAY more than Krita, which I am just starting to play with a bit more, but have already lost work due to a crash while working with a manipulation layer, and seeing as most of my work is either for web or black and white, I continue to use GIMP to get the work done. Hopefully Krita will continue to improve and I will be able to make the switch. Thanks for all of your hard work.
Since my screen is RGB and my printer driver requires RGB input, just exactly what is the supposed great advantage of so called CMYK images?
For you none, so don't use it. You can remove the plugin, or, if you're compiling, skip installing the cmyk plugins. Whatever floats your boat,
Most higher end printers (including moderately good consumer ones) use CMYK to print. If you were planning on having a professional printer print the image, then you would want to do it in CMYK.
This is not true. It is a common misconception, but it isn't the case. Most color printers use CMYK dye ink to print with. However, the drivers do not use a CMYK input. If you supply CMYK data it is first converted into RGB data before printing.
The reason for this is that the CMYK printing process is non-linear and has some color failure (dyes are not perfect). It is the printer driver that handles these issues when the driver converts from RGB to CMYK for a specific printer.
A professional print shop probably has software that can manipulate the image directly in CMYK, but you should still provide them with a RGB image unless you have software which is designed to work with the specific printer being used.
Oh, man. I know you mean well, and think you are always right, but really, this makes absolutely no sense at all.
Please, talk to some experts before you talk in public. People that have worked in the printing industry for many many years will tell you a quite different story.
Hint; ask about what a 'RIP' requires and outputs.
Please talk to a real expert before you tell people that making their own CMYK separations rather than having the printer driver do it will somehow improve their output.
If you are saying that I am wrong about something, it would be appreciated if you explained what you think it is.
With Linux, the RIP we use for printing is usually GhostScript combined with GIMP Print (being replaced by Gutten Print). This combination accepts an RGB image and produces a CMYK output which is specific to the printer being used.
Yes, as I said, commercial print shops may manipulate the CMYK image directly, but that isn't what I was talking about in my posting that started this thread. What I asked was if CMYK was of any use to someone using their own printer connected to their PC and using the standard Linux printing RIP (GhostScript/GIMP Print). Referr back to Corbin's posting which I was responding to. This was not about commercial print shops it is about Linux printer drivers.
You can't even *spell* correctly either one of Ghostscript, Gimp-Print or Gutenprint.
[And since your spelling in general is above avarage, this fact raises the strong suspicion that you *don't know* either of the 3 programs' working very well, which means your comments about this topic have to be taken with a spoonful of salt...]
I have: gutenprint-5.0.0-rc3 installed on my system.
I am a terrible speller and rely on the spell checker which corrected the misspelling of 'gutten'. :-D
"This combination accepts an RGB image and produces a CMYK output which is specific to the printer being used."
Again, not true in that total generalization you are using.
Gutenprint (formerly Gimp-Print) may be the most important printer driver family. But for HP models, there is HPLIP.
Also, if your printer is PostScript-enabled, your Linux printing will bypass Ghostscript entirely.
Whatever your verdict about CMYK for Linux imaging and printing is, JRT: I'm glad the Krita developers implemented support for CMYK (and continue to enhance it), and I'm glad you have no say in the process. (Please don't hate me for having said that.)
Notice the qualifying word: "usually"?
Obviously, if you are using a GhostScript "device" (regular or IJS), you don't use GutenPrint and if you have a PostScript printer, you don't run a RIP on your computer.
This is not my verdict about CMYK, it is fact that you don't need it to make prints on the color printer attached to your PC. The reason is that the printer drivers need RBG input.
The ability of Krita to handle other image formats is probably useful for some purposes -- you might need to import an existing image in such a format -- but it doesn't have any purpose in personal color printing.
Er... From the first moment you started I already said, no, cmyk is not useful for _you_. Just forget about it. We didn't code that feature for you, and if I could code it so that it wouldn't show up on your computer, I would do that. It's not on topic for you. You don't need the feature -- that's fine! I don't need it either. I haven't got a colour printer, even.
And I really hate to say it -- it's a dreadful thing to do -- but, despite the fact that I do believe you mean well and want the best, I think you act in a way that is actively detrimental to the progress of free software. Indirectly, actually, you're the reason I am the maintainer of Krita: you, in a very real sense, have driven away the previous maintainer by tiring him out. Us Krita maintainers, we may be wrong, proud, stubborn, irrascible, foolish and uninformed. But we're doing a job we're not paid for and I believe we are furthering the progress of free software. The environment we work in is touchy-feely, delicate and complex. Have a care.
Please. Can it. Stop it. You can make yourself useful to the cause of free software in another capacity, perhaps, once you learn how a free software community works. I'd like to help you with that, but you really need to learn to go with the flow. For instance, with the mindset you are displaying, you would be a wonderful regression tester, something that we are missing sorely. The person who notes that y.y doesn't do what x.x did, but in fact crashes on it -- we really need that. Miereneuken, as we say in Dutch. (Strictly untranslatable!) We don't need someone persistently insisting that feature A is not useful and computationally impossible feature B is necessary and insists on belaboring the obvious (as long as they are not regressions!).
Gnothi seauton -- know yourself.
Oops -- intermittent wifi network problems plaguing me...
Skepticism is a useful function. You get that with an engineer whether you want it or not. Cheerleading does not result in a better product.
The problem is not my skepticism but rather some ACs that are more determined to prove that I am wrong about something than to engage in a useful discussion of the product.
We still have ACs that are determined that they need CMYK for purposes which, as you said in a rather sarcastic way, it is totally unneeded. They also appear to think that just having CMYK will provide the features which I would really like to see.
It is not my fault that ACs are not interested in a useful discussion. It has previously been suggested that I ignore them and hope that they go away. Perhaps this is the best idea, but it is not my nature to do so.
Er... From the first moment you started I already said, no, cmyk is not useful for _you_. Just forget about it. We didn't code that feature for you, and if I could code it so that it wouldn't show up on your computer, I would do that. It's not on topic for you. You don't need the feature -- that's fine! I don't need it either. I haven't got a colour printer, even.
And I really hate to say it -- it's a dreadful thing to do -- but, despite the fact that I do believe you mean well and want the best, I think you act in a way that is actively detrimental to the progress of free software. Indirectly, actually, you're the reason I am the maintainer of Krita: you, in a very real sense, have driven away the previous maintainer by tiring him out. Us Krita maintainers, we may be wrong, proud, stubborn, irrascible, foolish and uninformed. But we're doing a job we're not paid for and I believe we are furthering the progress of free software. The environment we work in is touchy-feely, delicate and complex. Have a care.
Please. Can it. Stop it. You can make yourself useful to the cause of free software in another capacity, perhaps, once you learn how a free software community works. I'd like to help you with that, but you really need to learn to go with the flow. For instance, with the mindset you are displaying, you would be a wonderful regression tester, something that we are missing sorely. The person who notes that y.y doesn't do what x.x did, but in fact crashes on it -- we really need that. Miereneuken, as we say in Dutch. (Strictly untranslatable!) We don't need someone persistently insisting that feature A is not useful and computationally impossible feature B is necessary and insists on belaboring the obvious (as long as they are not regressions!).
Gnothi seauton -- know yourself.
> A professional print shop probably has software that can manipulate the image directly in CMYK, but you should still provide them with a RGB image unless you have software which is designed to work with the specific printer being used.
I hate to tell you, but you are soooooo wrong. I have submitted magazine ads for my business to around half a dozen publications and I can tell you in no uncertain terms they *REQUIRE* CMYK images. Manipulating RGB to CMYK is not the issue. Color matching the conversion is. As such professional printers have had experience with RGB to CMYK producing inconsistent results and customer issues. It's all about color matching which is why there is color matching software like lcms. In fact you can grab a few inkjet printers and print the same photo and notice differences. While the RGB in your image is specific, the conversion to CMYK can be somewhat arbitrary based on drivers. The professional printers use CMYK as that is how the ink goes on the paper. There is no probably about it. They will require CMYK. It's apples in, apples out, not oranges in, apples out. If a professional printer doesn't require CMYK that would throw up a #FF0000 flag for me. ;-)
Yes, color matching is the issue but is no need for CMYK to do color matching.
Yes, there are shops that won't do the RGB to CMYK conversion for you. And in that case, I stand by what I said that you must have software support for the print process that they are using.
If you don't adjust the CMYK separations to match their printing process, making them yourself simply won't result in any better output than using RGB.
Yes, different inkjet printers will produce different results. It would be very helpful if we had a way to preview these results on the screen. Since inks and papers differ (and with them the color gamut) it is probably not possible to get perfect matches from printer to printer. So, what we need is software that will give an accurate preview for every printer.
The objective of printing is to produce an RGB image. The best way to do this is to match a supplied RGB image. IIUC, the first problem here is that this supplied image must use color matching methods to conform it to the gamut of the printer. The second issue is desaturation of the image due to what in photo printing is called color failure (the fact that the dyes aren't perfect CMY -- specifically that the curves overlap slightly).
I would say exactly the opposite about a professional printer. If they tell you to make the separations, they are saying that they will not do the job of matching the output to what you want.
Your are basically right, some things a bit misleading. The facts:
1) Printing on your home-printer is done via RGB. No need for CMYK here.
2) The gamut of RGB is larger than CMYK. CMYK editing is necessary in professional production in order to prevent you from using colors during photo editing which cannot be printed later. This is not an issue at home, because you usually dont insert graphics or logos which must match a specific color but are simply retouching your photos. In the latter case, the color matching is better done later on to prevent color information loss.
3) The "K" (Black) in CMYK contains valuable information for printing which just isnt available in RGB. Negation of RGB would simply result in CMY. How much gray component is removed or added is represented by the K. Manipulation of this is done in professional printing and therefore CMYK editing is required though I agree this is a bit overkill with your average home-printer.
4) Simply doing RGB to CMYK conversion yourself will not yield any quality improvement. The opposite is true.
5) The corporate identity of many companies require that images, graphics etc match a very specific CMYK color. You can only guarantee that everything fits together nicely if you use CMYK images throughout in a document.
So to sum it all up: CMYK is absolutely required in professional print production for people who know what they are doing. If you just want to
retouch you holiday photos and give them to a print-office afterwards you shouldnt use this because you must know a lot about the production process, paper, etc to do it right. So it's better here to leave these issues to the print-office.
Good, an expert. My area of expertise is photographic color printing NOT 4 color ink printing. And it is a real bitch to match colors there also.
Re: #2: now we have established that I will be using RGB to drive my color printer, it does appear that a useful feature would be if there was some way to tell what was out of gamut for printing on my inkjet or a color laser printer at Kinko's. And, as I said, a color print preview would be very helpful. I know where out of gamut lies: too bright or too saturated, but don't know exactly where the line is.
Yes, that would be a useful feature in many apps indeed. In the mean time I can give you this hint in case you didnt think of it before:
Convert to CMYK and back to RGB. Subtract both images by layer filter. You get a map of problematic areas. This is where CMYK is helpful even in your case. Isnt it nice? We've now closed the circle of the discussion here ;-)
Bingo!
I don't think that that is going to make any difference since there is a direct correspondence between RGB and CMYK (for a given level of black removal). Changing from one to the other isn't going to indicate the reduced gamut of the printer which is a function of ink on paper vs. phosphors on the screen, not RGB vs. CMYK.
There isnt a direct correspondence if you use color profiles which you should. Without them RGB to CMYK conversion is not possible in a meaningful way.
This (color profiles) is something that I need a better understanding of. I am the first to admit that I do not fully understand it. However, I think that I know what I would like the software to do.
You can make an approximate (linear) screen preview of what a color print will look like with the matrix operation:
Image(preview) = [M]*Image(file) + [B]
where [M] is a 3x3 matrix and [B] is a 3 element vector. This function is applied (pixel by pixel) to the RGB vector for each pixel.
[M] makes the transform for the smaller gamut and color failure and [B] sets the black level.
I have not found any information as to how to produce these two paramaters for a given screen gamut (e.g. sRGB) and a color profile.
Linear is just a first approximation. A gamma corrected approximation (e.g. Gamma != 1) would be better. And, the best approximation is going to be non-analytic (curves not a linear or exponential function).
"Yes, there are shops that won't do the RGB to CMYK conversion for you."
No, James Richard, that was not the crux of the question.
The point is: even those shops which are able to do the CMYK-->RGB (and offer it as a service) -- them don't like it. Not at all. Because the results is less than stellar. And because the shops then have to deal with customers who complain and blame the shop's personell, equipment, expertise, customer care, knowhow for the bad quality and demand their money back....
"So, what we need is software that will give an accurate preview for every printer."
James Richard: that software's function is called "Color Management", using color profiles.
To be more precise, it means that your monitor needs to be supported by that color management as well.
Why? Because you need to get an RGB-based monitor [even different models/brands of RGB monitors!] to display the same color impression to the human eye as a CMYK-based printer [even different models/brands of CMYK and CcMmYyKk printers!]
All devices that "display" an image (RGB on screen, CMYK on printed media) need to be *adjusted* first. And need adjustment individually even, one for one. Even if you have 10 monitors of the same brand and model, they may have differences in their display, due to factory deviations, ya know?
(And Color Management software can never work perfectly anyway. Because some real life color shades may be *impossible* to display on an RGB screen. Which however may display just fine on a glossy paper printed with a 7 color inkjet. That's what is called the different "gamut" of the respective color spaces, James Richard. It's like the speed for driving your car: you "adjust" it with pressing the accelerator pedal. But you can never adjust it for going 300 mph, to match a Formula 1 racer, can you? However, you can adjust it to go slow, and with the same speed behind a bicyclist, and make both appear to go at the very same pace.)
Yes, I (basically) know how professional calibrated pre-press color management works. And, I know that it can't work perfectly because ink and phosphors are not perfect.
However, just because we don't have this in our standard software doesn't mean that we can't have anything. If we know that gamut that a printer can represent and apply this to a screen gamut (e.g. sRGB), we can display an approximation of what the printed page will look like. Naturally, if your monitor isn't adjusted correctly, this is going to vary, but it should give some idea of the reduction in the gamut when printing.