KOffice 1.6 Released

Tuesday, 17 October 2006 | Iwallin

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:

Bugfixes - Andrew Donnellan - 2006-10-17

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.

Re: Bugfixes - BKS - 2006-10-17

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! ^_^

fantastic - thank you - Gerry - 2006-10-17

Whatever else - has anyone noticed the speed with which the applications open now? Nigh-on instantaneous. Amazing, thank you.

Krita - Michael - 2006-10-17

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.

Re: Krita - younker - 2006-10-17

Just wonder will krita support raw format of each digital camera?

Re: Krita - Boudewijn Rempt - 2006-10-17

It already does -- using dcraw for now. For 2.0, I'll likely switch to Hubert Figuire's libopenraw.

Re: Krita - James Richard Tyrer - 2006-10-18

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.

Re: Krita - Boudewijn Rempt - 2006-10-18

We don't use a library right now; we exit to use dcraw, and that generates an 8 or 16 bit rgba image.

Re: Krita - James Richard Tyrer - 2006-10-18

So, there is no support for raw images.

Re: Krita - Boudewijn Rempt - 2006-10-18

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.

Re: Krita - James Richard Tyrer - 2006-10-18

> 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?

Re: Krita - max - 2006-10-18

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.

Re: Krita - James Richard Tyrer - 2006-10-18

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.

Re: Krita - ac - 2006-10-18

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.

Re: Krita - James Richard Tyrer - 2006-10-18

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.

Re: Krita - Boudewijn Rempt - 2006-10-18

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.

Re: Krita - James Richard Tyrer - 2006-10-18

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.

Re: Krita - ac - 2006-10-18

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 =).

Re: Krita - James Richard Tyrer - 2006-10-19

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.

Re: Krita - Kobus - 2006-10-17

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

Re: Krita - ac - 2006-10-17

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).

Re: Krita - Martin - 2006-10-18

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.

Re: Krita - ac - 2006-10-18

Sure. It can handle CMYK. Which I said. But how you can honestly say that its in the same league is beyond me.

Re: Krita - Jonathan Dietrich - 2006-10-24

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.

Re: Krita - James Richard Tyrer - 2006-10-18

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?

Re: Krita - Boudewijn Rempt - 2006-10-18

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,

Re: Krita - Corbin - 2006-10-18

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.

Re: Krita - James Richard Tyrer - 2006-10-18

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.

Re: Krita - ac - 2006-10-18

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.

Re: Krita - James Richard Tyrer - 2006-10-18

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.

JRT, Ghostscript, Gimp-Print and Gutenprint - AC - 2006-10-19

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...]

Re: JRT, Ghostscript, Gimp-Print and Gutenprint - James Richard Tyrer - 2006-10-19

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

JRT and his CMYK scepticism - AC - 2006-10-19

<i>"This combination accepts an RGB image and produces a CMYK output which is specific to the printer being used."</i> 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.)

Re: JRT and his CMYK scepticism - James Richard Tyrer - 2006-10-19

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.

Re: JRT and his CMYK scepticism - Boudewijn - 2006-10-19

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.

Re: JRT and his CMYK scepticism - Boudewijn - 2006-10-19

Oops -- intermittent wifi network problems plaguing me...

Re: JRT and his CMYK scepticism - James Richard Tyrer - 2006-10-21

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.

Re: JRT and his CMYK scepticism - Boudewijn - 2006-10-19

Re: Krita - Eric Laffoon - 2006-10-18

> 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. ;-)

Re: Krita - James Richard Tyrer - 2006-10-18

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.

Re: Krita - Michael - 2006-10-18

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.

Re: Krita - James Richard Tyrer - 2006-10-19

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.

Re: Krita - Michael - 2006-10-19

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 hope JRT sees a "CMYK light" now)... :-) - AC - 2006-10-19

Bingo!

Re: Krita - James Richard Tyrer - 2006-10-19

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.

Re: Krita - Michael - 2006-10-20

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.

Re: Krita - James Richard Tyrer - 2006-10-22

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).

JRT misundersts of parent postings (always!) - AC - 2006-10-19

"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....

JR needs to understand concept of color management - AC - 2006-10-19

"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.)

Re: JR needs to understand concept of color management - James Richard Tyrer - 2006-10-19

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.

JR, color gamut is not just about "inks and paper" - AC - 2006-10-19

"Since inks and papers differ (and with them the color gamut) [...]" James Richard, I see you have some idea about color gamut already. That's an excellent level educate yourself a bit more beyond these basics. I suggest you start up Konqueror and type "wp:gamut", "wp:RGB", "wp:CMYK" and "wp:color management" into the address field and do a bit of read up. It will teach you that even one RGB monitor differs to the next one. And one CMYK printer model to its neighbour. And a Scanner to the next. All of these need to be adjusted with a color management software to match each other as closely as possible, if you do some sort of professional printing. (Most home PC users may not need it -- serious amateur photographers however do long for it!) That's why CMYK support in Krita is absolutely essential. And I tell you one more thing: CMYK support in Krita would be absolutely useless if it wasn't accompanied with color management support (which is, I believe, in this case supplied by the LCMS library). Please stop bemoaning CMYK support in Krita just because you own an RGB printer (or a CMYK printer, whose crappy driver uses RGB as input.)

Re: JR, color gamut is not just about "inks and paper" - James Richard Tyrer - 2006-10-19

The color gamut of a printed page is determined by the ink and the paper. What this means is that the range of colors that can be produced is determined by the ink an paper. The color gamut of you monitor can be interpreted in two ways: 1. The actual colors which are being displayed. 2. The range of off monitor colors which FF0000, 00FF00, 0000FF represents. IIUC, it is #2 that color management software addresses. This works just the same with RGB since the color gamut is always an RGB function -- in the ideal case it is a triangle between a Red, a Green, and a Blue point. > Please stop bemoaning CMYK support in Krita just because you own an RGB > printer (or a CMYK printer, whose crappy driver uses RGB as input.) I am not bemoaning anything. I did seek to point out that you don't need CMYK to print on the printer attached to your PC. If the driver accepting RGB input is "crappy" then all of our Linux drivers based on GhostScript are "crappy". I am amazed at this superstition about CMYK. "The truth is out there." You use the "crappy" driver to convert a linear RGB image to a (printer specific) non-linear CMYK image which I hope is compensated for the color failure of the inks. The reason that you use the "crappy" driver to do this is that it has the needed information specific to the printer which is needed to do this. If you made your own CMYK separations in Krita and were able to directly print them on your printer, you would NOT be happy with the results -- the "crappy" driver (usually GutenPrint) does much better.

Re: Krita - AC - 2006-10-19

"The objective of printing is to produce an RGB image." No, it's not. The objective of (quality) printing is to produce an image on paper that matches as closely as possible the intentions of the artist, the photographer, the document writer or the user. (And this intention may well be "the printout and all its color shades must exactly match the picture I can see and adjust on screen".) The colors used could be based RGB, sRGB, CMYK, CcMmYyK and many more spaces... James Richard, the world does not evolve around your RGB fixpoint only. Like it or not.

Re: Krita - James Richard Tyrer - 2006-10-19

Well, my eyes see RGB. Therefore, ... .

Re: Krita - AC - 2006-10-20

"Well, my eyes see RGB." True. Mine as well. But the "world" of digital imaging and printing does not only consist of our eyes, but also of paper, inks, toners, monitors, rays + tubes and more, which all influence the outcome. In the end, there is again light reflected from a printed image which enters our eyes and is detected by our RGB-only light detectors.... OK, in this sense, the world *does* indeed orbit around RGB, and I must retract -- no, rather modify -- my above statement: # The world orbits around RGB, but there are other # components to this world but just that RGB axle.

Re: Krita - bluGill - 2006-10-20

Not really. Your eyes see RGB+gray scale. Cones and Rods and all that. I'm color blind, so I don't really see RGB, more like R1R2B, where R2 is somewhere between red and green - a very different color from red. There are many different types of color blindness (hundreds at least), but only 10% of the population have enough to matter. Even those who are not color blind have some shifting from "normal". So you think you see RGB because you are not color blind, but the colors are see are unlikely to be "a scientific standard" (AFAIK no such thing exists) RGB. Your perifferial vision is mostly black and white, your vision in front of you is color. And there is also that blind spot. Depending on how you look at an image you get different combinations. Your brain is smart enough to fill things in so that you don't realize this is happening, but it does. Odds are you knew the above already, but never considered it. You should. CMYK is the best chance we have to cover all that complexity, which is why professionals use it. It still doesn't cover people like me very well, but it is pretty close for 90% of the people. When colors are really important professionals will buy an ink in that color, but each ink requires a separate pass through the press (some presses can do more than one color in a pass), and each pass will be a little misalligned from the previous, so this is rarely done anymore as CMYK is almost always close enough and there is no missalignment problem. A few years back my brother was assigned to calibrate a $60,000 CMYK printer. To some Pantone (tm) color - the closest that printer could do was visually different from the standard. A $100 inkjet was able to get it perfect (at least as far as anyone could visually see, color blind or not). So lets not pretend that CMYK is perfect, but it is what professionals use. (P.S. Anyone know when Microsoft is going to update their stupid browser to get spell check - something Konqueor has had for year? I wish I was allowed to use something better here)

Re: Krita - James Richard Tyrer - 2006-10-21

> ... the closest that printer could do was visually different from the > standard. A $100 inkjet was able to get it perfect ... This is an inherent problem with CMY or CMYK printing. In CMY photo printing it is called color failure. I presume that with ink that this varies from ink set to ink set. The problem is that the secondary color dyes aren't perfect. The Magenta ink absorbs some Green and the Cyan ink absorbs some Yellow. The Yellow ink is usually not a problem. So, what happens is that when you combine two of the CMY inks, you get a little Black. With photo printing you have to make masks to compensate for this. With CMYK it is simpler. A printer driver that compensates for color failure subtracts this extra Black from the K channel. However, this still means that there is a maximum for saturation and brightness for the primary colors -- the reduced gamut. With ink printing using more colors helps eliminate this problem.

JRT and his RGB/CMYK understanding - AC - 2006-10-19

Most printers (even cheap inkjets) have their inks and toners in CMYK. Yes, your screen is RGB. And yes, *some* printer drivers use (and require) RGB input. But *no* -- don't think that means "there is RGB in my computer all over the place". What format your computer uses internally is something else ("CoreGraphics Engine" [CGE] for Mac OS X, "Graphic Device Input" [GDI] for Windows, and PostScript for Unix/Linux) as originating format that goes to the printer driver...

Re: Krita - Guillaume Laurent - 2006-10-19

I concur on the great progress on krita. Last time I tried it (I believe it was 1.5), it was pretty frustating (and I made a negative comment here), but it has obviously made *a lot* of progress. Congratulations and thanks, here's to hoping I can forget about Gimp soon.

To report a bug or file a wish - Jaroslaw Staniek - 2006-10-17

Please use http://bugs.kde.org rather than commenting here, so your report will be noticed. Thanks.

Vote! - Stefan Nikolaus - 2006-10-17

I want to encourage everyone to vote for features KOffice lacks of. If the missing feature is not yet filed in bugs.kde.org, don't hesitate to do this yourself. Developers are busy with coding, you know. ;-) Most developers have a look at these wishes and the number of votes to see where KOffice or any other KDE app needs improvement. Using bugs.kde.org ensures, that your wishes don't get lost due to the fading memories of the species called software developer. The same applies for bugs. Some notes about the voting system: You can assign up to 20 voting points to a wish and up to 100 points per product, e.g. KSpread. So you can give 20 points to each of the five most important missing features of KSpread, for example. If you consider more features as important, distribute the voting points among them. Happy voting!

Re: Vote! - Former KOffice user - 2006-10-17

I would rather they work on fixing all the bugs that make KWord, KSpread, and KPresenter unusable. Sadly, if you want to do some actual work rather than just play around with a cool app, OOO is still the only choice on Linux. We honestly tried to stick with KWord at least, but in the end it is just plain not feasible. Import/export from/to MS or at least OOO formats is one showstopper for example. I will try out Krita next time I need to edit an image though.

Re: Vote! - Stefan Nikolaus - 2006-10-17

Bugs are fixed by developers, but KOffice lacks of enough manpower. Hence, we need to prioritize and that are votes for (even though developers are aware of the main issues).

Re: Vote! - superstoned - 2006-10-17

many of the bugs you experience are due to limitations in Qt 3.x, and will be fixed in the 2.0 release. And don't count on better MS Whatever importfilters, they don't want to waste time on that. OO.o support isn't even needed, as OO.o and Kword use the same fileformat. both do still have some bugs in there, but i guess that's something which will be fixed as time passes.

Nice picture! - ac - 2006-10-17

Yayy!! The picture on KOffice website and Cyrille's blog is really nice, looks clean and professional :)

Thanks. - Emanuele Gissi - 2006-10-17

First of all, thanks a lot for your work on KOffice. I download each release and try to use KOffice for daily use at work. The suite improves with every release and this is really impressive! But, at end, I still go sadly back to OO.o with all its defects... What I lack more are good doc and xls export filters. It's really sad, but I often need them. It would be a dream if we could split OO.o import/export filters in a library and include them in KOffice. As I am not a developer, I don't know if it would be theoretically feasible. I can ...pray and propose a bounty if someone is interested... Thanks once more. Emanuele.

Re: Thanks. - Anonymous - 2006-10-17

http://ariya.blogspot.com/2006/04/why-koffice-not-using-openofficeorgs.html

Re: Thanks. - Philipp - 2006-10-17

For Word you have the RTF filter. Nothing special with it, just try to save in Word 2003 in 2000 format and you also only get RTF. If you prefer another ending, than do like Word and change .RTF to .DOC. For Excel it's missing, known issue.

Re: Thanks. - Ascay - 2006-10-17

The files you want to import are usually from *other* people. And to tell a customer to send you a standardized format (doc/xls/ppt is a standard for him and he knows no other formats anyway) or how he could transform it into something you can import appears to be... not really the best way.

Re: Thanks. - bluGill - 2006-10-17

You should anyway. If enoguh customers scream at Microsoft that their partners are having trouble opening documents, maybe Microsoft will change to a good format (opendoc...) that everyone can open. There are enough non-Microsoft office products in use that if every user of them made sure to point out the problems they have opening Microsoft documents to partners, the partners would also scream. Loud enough to get Microsoft's attention. Yes I know not everyone can do this. I specified partners for a reason. You can't inconvience custmers. You can inconvience partners a little, and suppliers had better fit to your needs or you will find a new supplier. (You can even write this into contracts and bid requirements in some cases) Micorsoft's .doc format is a mess. There is good reason that they use .rtf to save to formats for older versions of word - they cannot understand the format themselves.

the announce has been translated by a robot ? - oliv - 2006-10-17

I clicked on the "announce" link, then went to the French translation... it is full of mistakes (one per line, and I am not talking about typos here). I think it is far better not to put online any translation than to put a very bad one. I guess it was done by some automatic translation program (google trans, babelfish, etc.).

Re: the announce has been translated by a robot ? - Albert Astals Cid - 2006-10-17

I'm the coordinator of annoucement translations and I'm sorry the translation is low quality. I sent the annoucement to be translated to a person, if that person used an automatic translator, that is bad. I will check with him.

Re: the announce has been translated by a robot ? - turman - 2006-10-20

I don't know if the page has been updated but now the translation is very good for me.

Command-line scripting - Anonymous - 2006-10-17

> With this release, KOffice also introduces command-line scripting where, for > example, spreadsheet documents can be automatically manipulated with scripts I tried to find some documentation on this feature and how to use it but didn't find anything on the koffice website. Does anyone know where I could find some documentation on how to use this feature ?

Re: Command-line scripting - Boudewijn Rempt - 2006-10-17

For Krita, see the manual: http://docs.kde.org/development/en/koffice/krita/scripting.html.

Re: Command-line scripting - Sebastian Sauer - 2006-10-18

A small example for KSpread is up at http://kross.dipe.org/KSpreadInvoiceExample.tar.gz Do we have doxygen API references for 1.6 up somewhere? They are nice to look at the functions + examples for scripting too.

Re: Command-line scripting - Sebastian Sauer - 2006-10-18

and some more examples; http://www.kde-files.org/index.php?xcontentmode=617 http://www.kde-files.org/index.php?xcontentmode=618

Re: Command-line scripting - Sebastian Sauer - 2006-10-18

and for Kexi, you may also like to look at; http://www.kexi-project.org/wiki/wikiview/index.php?ScriptingHandbook

Dead in the water - Mike - 2006-10-17

It's good to see KOffice being upgraded from time to time, but I get the impression that the 1.x branch is officially dead in the water. There are issues that won't get fixed until the 2.x branch, such as support for OpenDoc/Word etc... Without them KOffice is unusable by anyone that needs to inter-operate with people who use MSOffice or OpenOffice. This is the reason I gave up on KOffice recently and moved to OpenOffice.

Re: Dead in the water - superstoned - 2006-10-17

Sorry, but what are you talking about? MS Word support won't ever get better, they don't want to waste time on proprietary sh*t. And they shouldn't. OpenDocument has been supported since quite some time, it's the default fileformat, so that's not a 2.0 thing as well. It's true 2.0 will fix some longstanding issues, but those are mostly layout issues in Kword, and have nothing to do with fileformat support.

Re: Dead in the water - Corbin - 2006-10-17

KOffice was one of the first office suites to have native support for OpenDocument, also in a lot of areas KOffice is closer to the ODF standard than OOo, though both suites are still working on it. And 1.6 release and 2.0 release were being developed at the same time, now that 1.6 is out the door, unless theres plans for a 1.6.1 release, all the effort is going to go to 2.0.

Re: Dead in the water - Inge Wallin - 2006-10-18

There will be a 1.6.1 release and possibly also a 1.6.2. Those releases will only have bugfixes and no new features. However, errors in OpenDocument handling (a.k.a the OOo) are considered bugs so incompatibilities with OOo should be reported. It's very likely they will be fixed in the 1.6 series. Regarding XLS and DOC support, it's not exactly that we "don't want to waste time with that shit", it's more like "we have nobody who has prioritized it high enough". We would love better XLS and DOC filters, but at this time we have nobody who works on them.

KOffice for Windows - Alex - 2006-10-17

So when is KOffice for Windows coming out?

Re: KOffice for Windows - Boudewijn Rempt - 2006-10-17

With version 2.0, probably at the same time as the Linux and OS X versions. Although that will, as always, depend on people using those operating systems helping out. The most recent Windows I own is 3.11, and the most reason Windows I have access to through my workplace is Windows 2000...

Re: KOffice for Windows - Anonymous - 2006-10-18

If you want to have a look for yourself without a newer Windows, you could still test with ReactOS (www.reactos.org), it should probably be far enough to run the KOffice2 suite, as it already handles OpenOffice for example.

Re: KOffice for Windows - Casper Boemann - 2006-10-18

I guess what Boudewijn was trying to say is that none of us developers really care enough for windows to go the extra mile to install another OS. Choosing between spending our time on improving KOffice prober or doing auxillary testing we choose KOffice any time. But given a concrete bug report on how to make it work on windows (patch even more appreciated) I suspect we would spend some time on it. And as Boudewijn said: With 2.0/QT4/KDE4 we will work on windows almost out of the box, so chances are great that it will happen then.

Re: KOffice for Windows - Inge Wallin - 2006-10-18

Now, Casper, that's a very callous attitude. I know some developers care very much that KOffice will work on Windows. I am fairly sure that Jaroslaw Staniek, for instance will make sure that it works well when the time comes. I myself care also, but unfortunately I have never developed on Windows so I wouldn't have any clue about how to do it.

Re: KOffice for Windows - Sebastian Sauer - 2006-10-18

In fact it works already since some time on MacOS and there are already some older packages around. See http://ranger.users.finkproject.org/kde/index.php/Home http://dot.kde.org/1073009304/ http://www.racoonfink.com/archives/000700.html

Do not port to windows! - MSLinux - 2006-10-18

http://www.fefe.de/nowindows/

Re: Do not port to windows! - Alan Horkan - 2006-10-19

that ship has sailed windows ports will happen sooner or later the trick will be to balance the risks and rewards promoting standards will be one of the biggest rewards porting KOffice and getting more people using OpenDocument will be good for everyone. wouldn't you love it if you didn't have to tell people not to send Microsoft word documents? i look forward to a khtml/webkit browser on windows so that web developers will have one less excuse for not testing their web pages and following standards. I would strongly favour not porting Konqueror to windows because of the risks of it not being as good as on KDE and giving people the wrong idea. having a standalone khtml/webkit browser instead would help promote standards without risking any of KDEs reputation. unfortunately the swift web browser project seems to have stalled due to financial difficulties. applications which help promote standards should definately be at the front of the queue when it comes to windows ports

Re: KOffice for Windows - bluGill - 2006-10-18

Some people care, some do not. Like Boudewijn Rempt, the only version of Microsoft Windows I have legal access to is 3.1 (if the disks are still good and I can find a working floppy drive...) I am forced to use Windows XP at work, and I hate it. I personally am not going to put any effort into getting Koffice working on Microsoft Windows - in the end I would have something I have no use for. I will allow others to do that work if they want. I even wish them luck. But I'm not interested in helping. Many other Koffice developers are the same. (note, though it appears I'm lumping myself in with Koffice developers, I have not actually submitted a patch, only played with the source a little) The question is will those who do care about Microsoft Windows care enough to put the work in to make everything work? It appears there won't be much work, and in that case they will do it. However if it turns out there are major work involved those are care may not care enough to do the work.

Re: KOffice for Windows - Eric Laffoon - 2006-10-18

I personally don't care to spend any time developing Quanta for Windows. In the past it would have meant thousands in software licenses including a copy of the MS compiler and months of dedicated developer effort in porting. None of our team likes Windows and everyone especially dislikes developing on it. Having said that it doesn't matter. It's like OS X or BSD... Once somebody is building on it they let us know where our code doesn't build and specific guidelines to make sure the code is cross platform. This usually amounts to very little effort on our part. So we focus on what we wanted to do in the first place, making our application as good as we can, and others make sure we are building on other platforms. In KDE 4 Windows is just another platform. In my opinion having our applications on Windows is a good start for migrating people to free software... The Qt4/KDE4 scenario is the all the difference in our support for Windows.

Re: KOffice for Windows - Well - 2006-10-24

Well said.

Krita - Marketing vs. Reality - max - 2006-10-18

"Krita Becomes Usable for Professional Image Work [...]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." Krita looks nice on paper (nice architecture, nice concepts,...) but let's have a closer look: Best free image editing program? Does it have 16bit? - Yes Does at least the most basic filters (like unsharp mask, Gaussian blur,..) work with 16 bit? - No That's a joke, isn't it? I just tested the raw-import feature (it works basically) but then it's impossible to sharpen the image because "unsharp mask" (the only adjustable sharpen filter in Krita) only supports 8 bit/color. Why is Gimp still extremely popular despite the lack of >8bit/color, color management, CMY,...? It's *not* because of the cool features of Qt4 (gimp uses older versions of gtk), it's also *not* because of it's intuitive ;-) GUI but it's *because* _the_basics_just_work_ and it has very *many* filters and scripts. Krita lacks filters, plugins, intuitive color adjustment tools,... That's the main disadvantage of Krita at least from a point of view of an end user. All those rewrites and new Qt4 and KDE4 features _won't__make__Krita__any__better if color adjustments, performance and all the other filter plugins are worse than the corresponding plugins from Gimp or Digikam. Always saying "wait for the next version" does not work. Who will start writing plugins and scripts for Krita if Krita 1.6 will be a short living bugfix only branch (as krita 1.5 was) and Krita 2.0 will probably be incompatible again with existing Krita 1.6 plugins? After Krita 1.5 was released (professional photo manipulation software, now with scripting support...) I tried to write a script to do "unsharp mask" sharpening. But argh - Krita had no funktion to do gaussian blur (that's a basic and needed for nearly everything...) - so no script. Should I write a vignetting and distortion correction plugin for Krita 1.6? I don't think that's a good idea because Krita 1.6 won't see any significant updates anymore (only some bugfixes, if I remember correctly) and Krita 2.0 is too far away (I won't install KDE 4 before KDE 4.0.2 or so). Gimp does not have those strong dependencies to special KDE or Gnome versions.... Why not remove the feature freeze from Krita 1.6 and have a nice and long living Krita 1.6, 1.7 branch?

Re: Krita - Marketing vs. Reality - Paul Eggleton - 2006-10-18

> and it has very *many* filters and scripts. Krita is much newer than GIMP. Give it some time. > Gimp does not have those strong dependencies to special KDE > or Gnome versions.... That's because GIMP is already fairly well established and its development (as far as I know) is not moving at a particularly fast pace anymore. When they move to the GEGL core however you can bet that GIMP will depend on much newer libraries in order to increase functionality. > Why not remove the feature freeze from Krita 1.6 and have > a nice and long living Krita 1.6, 1.7 branch? Because there aren't enough developers to work on significant features in Krita 1.x *and* Krita 2.0 at the same time. Qt 4 offers a much more powerful toolset for developers to work with, and to make Krita the best painting tool it has to be developed to take advantage of Qt 4's new structures and features. I think a lot of people don't fully appreciate this yet, and I guess it won't be obvious to many until KDE 4 is released with lots of cool new stuff that Qt 4 has made possible. > Should I write a vignetting and distortion correction plugin > for Krita 1.6? I don't think that's a good idea because Krita 1.6 > won't see any significant updates anymore (only some bugfixes, if > I remember correctly) and Krita 2.0 is too far away Krita 1.6 will be around for a while in terms of usage, and if you have any intention of using it at all, surely putting work into a plugin now won't be completely wasted if there are still users around to make use of it. Chances are porting a plugin to 2.0 won't be all that hard when it does finally get released either.

Re: Krita - Marketing vs. Reality - Max - 2006-10-19

> Krita is much newer than GIMP. Give it some time. Of course. But then they should not call Krita the "best free image editing program". >Because there aren't enough developers to work on significant features in > Krita 1.x *and* Krita 2.0 at the same time. Then I would concentrate on the Krita 1.5 code base. But I'm not a developer. > Qt 4 offers a much more powerful toolset for developers to work with, and to > make Krita the best painting tool it has to be developed to take advantage > of Qt 4's new structures and features. Wrong, you do not need Qt4 to make a good painting tool. Painter, Photoshop 6, Picasa, Bibble,... all use older and simple toolkits. A image editor does not become magically better only because of Qt4's new painting engine or file dialog. It's all about Workflow, Usability, image editing capabilities and Plugins. > I think a lot of people don't fully appreciate this yet, and I guess it > won't be obvious to many until KDE 4 is released with lots of cool new stuff > that Qt 4 has made possible. Forget this cool new stuff until the basics work. If Workflow, Usability, image editing capabilities and Plugins are top notch then it's time to think about requiring a new Qt or KDElibs version.

Re: Krita - Marketing vs. Reality - Paul Eggleton - 2006-10-19

> But I'm not a developer. Which is why I think you may not appreciate that sometimes in software development, you have to stop working on the currently released version of a piece of software in order to pave the way for future development. Staying working on old versions does have its benefits, but you may spend a lot of time implementing features that would be much quicker to implement once you have been able to rework the underlying structures, which you can't do without risking the stability of the application. In a development version (Krita 2.0 / KDE 4 in this case) you are allowed to change a lot of stuff under the hood that might break things initially but will eventually result in a stronger base for future work. At some point you just have to make that leap. > Wrong, you do not need Qt4 to make a good painting tool. > Painter, Photoshop 6, Picasa, Bibble,... That's a somewhat specious argument - they just wrote their own code rather than relying on a toolkit that is already built. Let's not forget either that all of those products (I assume, since I know of all of them except Painter) were developed by commercial entities with significant amounts of money to spend on development resources, unlike Krita. Some of them, such as Photoshop, have been around for many years and thus are much further along than Krita. It's not a particularly fair comparison. I wasn't suggesting that Qt 4 is a magic bullet, either - it just provides a much more capable foundation than Qt 3. > Forget this cool new stuff until the basics work. People have different ideas about what the "basics" are. Some of the things you consider "basics" might not necessarily be trivial to implement.

Re: Krita - Marketing vs. Reality - Boudewijn Rempt - 2006-10-18

Yes, you should write plugins for 1.6. There is a plugin writing manual, there's nothing to stop you :-). You can release it separately and then, when 2.0 stabilizes contact us about it. We can then port it and put it in the main tree for 2.0. I think that Krita 1.6 will live for at least a year from now, and there will be one or two bug fix releases. By the way: the downgrade message for unsharp mask with 16/bit channel images is a bug: in fact, all convolution filters work just fine with 16 bits/channel images and don't downgrade. (Except for lab, apparently -- but that already works in trunk, too.)

Re: Krita - Marketing vs. Reality - Thomas Zander - 2006-10-18

> when 2.0 stabilizes contact us about it. We can then port it and put it > in the main tree for 2.0. One of our developers ported his plugins to the trunk codebase in no time. I estimate he spent 1 or 2 hours per plugin of quite reasonable size. I think its good that you (Max) care and focus on the things that are needed. I'd love to see you put your foot down and convert your activism to productive output. Thanks

Re: Krita - Marketing vs. Reality - Boudewijn Rempt - 2006-10-18

Oh, and really: here's a hard offer. I will do the porting work for everyone who builds a fun and useful filter for Krita 1.6 and wants his filter in Krita's main distribution.

Re: Krita - Marketing vs. Reality - Max - 2006-10-19

I will come back on you. Maybe I'm writing a usable Lens Correction filter or try to port Mplayers high performance unsharp mask filter and bicubic scaling filter.

Re: Krita - Marketing vs. Reality - Boudewijn - 2006-10-19

I'm looking forward to it!

Re: Krita - Marketing vs. Reality - Cyrille Berger - 2006-10-18

> Should I write a vignetting and distortion correction plugin for Krita 1.6? whats' wrong with the one allready included ? as for color adjustement, we only miss level, but then nothing prevents you to add it to 1.6, the change to 2.0 and Qt4 won't make it hard to port filters, for them, most of the internals of krita 2.0 will stay the same as 1.6.

Re: Krita - Marketing vs. Reality - Max - 2006-10-19

>> Should I write a vignetting and distortion correction plugin for Krita 1.6? > whats' wrong with the one allready included ? It's unusable. Have you ever tried to adjust more than one or two photos with it? Hint: Take a digital camera with zoom and take 100 photos with different zoom levels and different apertures. Then try to adjust those photos with Krita... Distortion depends on camera model and focal length. Vignetting depends on camera model, focal length and aperture. Does this filter read those informations from the exif tags? No. Does the filter at least support user defined profiles (e.g. distortion correction for a some camera model at 35mm, 50, 80 mm focal length)? - No For each photo you have to fiddle with at least three numerical values until it looks right. How to do it right? Look at Bibble or just guess/calculate the distortion values from vertical lines. > as for color adjustement, we only miss level, "We only miss level?" How do I increase or decrease saturation? How do I remove points from the Brightness/Contrast curve? Suggestion: Combine "Color Adjustment" with "Brightness/Contrast" as nearly all other programs do. How can I easily adjust the color temperature. "Click white point"... > but then nothing prevents you to add it to 1.6, the change > to 2.0 and Qt4 won't make it hard to port filters, for them, > most of the internals of krita 2.0 will stay the same as 1.6. As I wrote: Krita 1.6 is missing many small, but needed features and it does not seem those features will make it into Krita 1.5.x. And KDE 4.0.2 is still very far away (KDE 4.0.2 is the earlyest I and many other people will be able to switch to Krita 2.0) which unfortunately makes Digikam or Gimp 2.3.x/2.4 more appealing. Btw.: Do you plan to improve the image preview in the filter dialogs in 1.5.x? Will it be possible to use Digikam-Image-Plugins in Krita 2.0? But keep up the very good work(!) and don't let you demoralize by someone who would prefer an improved Krita 1.7 much more than Yet-another-kde-4.0-only application.

Re: Krita - Marketing vs. Reality - Boudewijn - 2006-10-19

I do hope I'll find a way to reuse the digikam plugins for 2.0; probably not the kipi plugins since Krita is not the application to manage your photo collection with. I tried for 1.5, but I got hopelessly confused by which part of digikam I would have to fake to make the plugins work: there is not a really clear interface that I can just implement for digikam to access krita's image data. Especially when selections come into play. I thought it would be necessary to actually copy Krita's non-rectangular selection data onto a new transparent image, and then send it to digikam's plugins. You can remove points from the brightness contrast curve by right-clicking them (I believe -- I actually use Krita most for painting, not for photo retouching. That's more Cyrille's lookout).

Re: Krita - Marketing vs. Reality - Max - 2006-10-19

> You can remove points from the brightness contrast curve by right-clicking > them (I believe -- I actually use Krita most for painting, not for photo > retouching. That's more Cyrille's lookout). Does not work here (Krita 1.6.0)

Re: Krita - Marketing vs. Reality - Boudewijn - 2006-10-19

Hm, then its probably another key... I know it's possible, I just don't ever get the time to actually do it :-). Maybe something for a thorough usability review some time soon before the next release?

Re: Krita - Marketing vs. Reality - Casper Boemann - 2006-10-19

simply select the point and press delete on the keyboard

Re: Krita - Marketing vs. Reality - max - 2006-10-23

Thanks, I did not see that it is possible to select points. The visual feedback is not easily to see. The lack of a context menu did ot help, too.

Re: Krita - Marketing vs. Reality - caulier gilles - 2006-10-20

Hi Boudewijn, how are you ? There is a clear interface for all image plugins used by digiKam image editor and showfoto. Look the ImageIface class implementation from trunk : http://websvn.kde.org/trunk/extragear/graphics/digikam/utilities/imageeditor/editor/imageiface.h?rev=563320&view=auto But since digiKam support 16 bits/color/pixel and advanced photograph metadata, we don't use QImage to store image data but a dedicaced container named DImg using a similar syntax than QImage : http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/dimg.h?rev=557529&view=auto If you need help to support digikam image plugins in Krita, let's me hear... Gilles Caulier

Re: Krita - Marketing vs. Reality - Boudewijn Rempt - 2006-10-20

I'm fine -- much better than this summer :-). I'd love some help interfacing between Krita and Digikam! On the krita side, all that's necessary is to create a digikam-filter filter plugin that converts the krita data to dimg data and back and that can access the digikam filter settings dialogs.

Re: Krita - Marketing vs. Reality - Caulier Gilles - 2006-10-20

And me, i'm very tired. digikam 0.9.0 is now in beta3 and we working hard to release final before Christmast 2006 (:=))) There are a lot of new features, like geolocalization of picture, Metadata editing, etc... The krita digikam-filter need to be linked with shared libdigikam.la library to running. it's not a problem for you ? Ah, before to forget, i have tested last krita 1.6-beta1 release provided by Mandriva 2007, and i have found a little problem with PNG files : the text chunck are definitivly lost after editing. For photograph, this is _VERY_ important to preserve this data (easy to do using libpng) since ImageMagick/GraphicsMagick/digiKam/ExifTool use the same way to store EXIF/IPTC/XMP to this area like a bytearray. You just need to save in memory tese bytearray and rewrite is into target PNG file. Look "PNG TextualData Tags" list from this page : http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/PNG.html Nota : the same way can be done if you want to convert without lost metadata from a PNG image to TIFF or JPEG file (and vis-versa). Gilles

Re: Krita - Marketing vs. Reality - Boudewijn Rempt - 2006-10-20

I wouldn't mind; it would be an optional dependency or something like that. The exif thing is for Cyrille to fix :-). I'll get back to you in a few weeks -- when you've had time to rest a bit. I'm generally speaking quite jealous of your coding speed!

Re: Krita - Marketing vs. Reality - Caulier Gilles - 2006-10-21

>I wouldn't mind; it would be an optional dependency or something like that. >The exif thing is for Cyrille to fix :-). I'll get back to you in a few weeks >-- when you've had time to rest a bit Well digikam 0.9.0 final release is planed just before Christmast. We can talking about by mail directly without problem and when you want. > I'm generally speaking quite jealous of your coding speed! (:=))) thanks. Working on digiKam & co is very important for me (and for all photographs witch use linux, i hope)... Gilles Caulier

Re: Krita - Marketing vs. Reality - Cyrille Berger - 2006-10-20

> How to do it right? Look at Bibble or just guess/calculate the distortion > values from vertical lines. Wow just telling me this without looking to shout at me would have been so much nicer :D Except that is useless as bibble isn't available for free, so I can't test it. And while I do a little photography, I never correct the distortion as my numeric camera does it automaticaly for me, so nice input on the plugins is allways welcome :)

Re: Krita - Marketing vs. Reality - max - 2006-10-23

> Except that is useless as bibble isn't available for free, so I can't test it. You can test it for a month (or two weeks). Just download the rpm or deb, it works on nearly every x86 or x86-64 distribution. http://download.bibblelabs.com/download/distribution_list?download_data%5Bfirstname%5D=&download_data%5Blastname%5D=&download_data%5Bcompany%5D=&download_data%5Bemail%5D=&commit=Continue Additionally the learning videos (on the same download page as above) might be interesting for you.

Re: Krita - Marketing vs. Reality - James Richard Tyrer - 2006-10-22

I would be the first to admit that cheerleading doesn't really help much. However, Krita is still a work in progress. I hope that it has now reached the point where I can do enough work on it to help with the debugging efforts. So, if it is usable, try to use it and report what doesn't work yet. This is needed since without a user base, it will only do what the developers think to test.

Re: Krita - Marketing vs. Reality - Boudewijn Rempt - 2006-11-06

"Does at least the most basic filters (like unsharp mask, Gaussian blur,..) work with 16 bit? - No." Actually... They do, mostly, but there was a spelling mistake in the code that meant that a warning was spuriously displayed when applying these filters to 16 bit rgba code. Fixed for 1.6.

Simple gradient in Krita - sebastian - 2006-10-19

Can someone tell me how to do this in Krita? I picked two colors. Now I want to fill a selection with a linear gradient where the one color fades to the other from one side to the other. The default gradient gives me something where the one color is in the center and the other at both edges and I simply can not adjust anything. The custom gradient does not seem to work for me. And there is another thing: In Photoshop they have an infobox. When I start a gradient fill (or a line or whatever) with my first mouse click it shows the position of this first mouse click and the current position of the mouse as well as its relative coordinates with respect to the first click (including arclength, angle in degrees and rad...) Is there such a box in Krita as well?

Re: Simple gradient in Krita - Boudewijn Rempt - 2006-10-19

Hm, the custom gradient did work when I just tested it -- and the gradient Krita painted went nicely from left to right, from orange to green. We haven't got an infobox yet -- but we would love to :-)

Re: Simple gradient in Krita - Max - 2006-10-19

> The custom gradient does not seem to work for me. Works for me (Krita 1.6.0)

Wow - forrest - 2006-10-20

there are over 100 comments!! Anyway... I really hope Kexi does take off. Kudos to all the devs!! I also really hope KWord is da bomb in KOffice 2.0. I see it as KDE's potential 'killer app' (not mentioning Amarok, K3B, etc :)). Cheers