Today marks a big achievement in the development of Scribus 1.3.5. As of now, we no longer use Qt3 or its support classes. YAY. A big job - one that started out as very simple but right at the end took awhile to get finalised. Its a nice feeling to have that sorted and now [...]

So I arrived today in Glasgow, a little bit in advance for the Akademy, but there was two reasons for that, a less expensive ticket and that leave me sometime to visit the city. So here is a first glance:

Ok I am a bit unfair, but that factory stroked me the first time I saw it, I was looking at a nice view, some trees in the background, a brick house in the foreground, and then I walked further, and among the trees there was that factory. And somehow I like that picture, and it's possibly a good summary of Glasgow, a mix of traditionalism and industrialism.

Troy asked us in a general questionnaire about Krita if we had any good image made with Krita, which reminds me that I haven't taken the time to do any real playing with Krita since so long that I can't remember when. So, instead of doing more usefull work (like a summary for an article, cleaning my apartment, and walking outside in the sun). I took one of the last comic I bought (Orbital for the french among you, very good stuff, the background of the universe is a little bit cliché, but the story is quiet good) with really gorgeous drawing. In other word, really good stuff if I want a decent end result.

This is an answer to a comment from Bruce on my previous post, and the reason why I favor more XMP than RDF; at least at the moment. I will start by saying no decision have been taken on whether Krita should be "limited" to XMP (or RDF), or whether OpenRaster will be using XMP instead of RDF.

XMP is subset of RDF

So XMP is a subset of RDF and doesn't support all the features of RDF, and it's using an older version of RDF. I can understand that it makes it harder to use a RDF parser to manipulates XMP data, but from my point of view it's hardly a problem, as long as XMP allows to do everything I want to do in metadata in Krita. Then, I would add that supporting XMP is important because it's quiet well established in the graphic world.

Images are not pixels alone, they include metadata. Whether they are automatically generated by a system, for instance every digital camera saves information about the condition under which a picture has been taken, some other metadata are created by the user, including, for instance, a description of the content of the image so that it is then easy to find it again in a search engine (think about Strigi or/and Nepomuk).

It might sounds like I am telling banalities, but today one of my fellow Krita developer asked me what I was doing those days, and then after I answered that I was, among other things, working on KisMetaData, he was a little bit puzzled by what the use case could be, the second thing is that metadata in Krita has always been less than suboptimal, we were more or less trying our best to not lose them, but even at that we were failing (for instance IPTC tags in Jpeg, and most metadata information in PNG or TIFF, sometimes because of lack of real standardization and/or lack of support in the files libraries). And an other problem of metadata in 1.6 is that the engine was closely related to Exif, even if it was extensible beyond what Exif supports.

An efficient tracking of the mouse is essential for painting application, and input event system (whether X11 or Windows) doesn't report all mouse move event, especially when the mouse move fast, and what the user might want to see as a round end up being a polyline.

The black stroke was made without smoothing, and the red one with smoothing.

The solution I used was to draw Bezier curve (like in vector application) between two input events, instead of lines. The biggest problem is to guess the tangent around the points given by the input event system, because the painting program need to compute the tangent without knowing what will be the next mouse move. There are some possible workaround, like delaying the drawing of the last strokes until next user input or more subtle would be to repaint the last strokes when the full information available. But I am quiet satisfied by the results I get with the current cooking of the tangent.

I am pleased to announce that the latest bug fix release of KOffice 1.6.3 is out. You can read the full announcement here. For Krita, this release includes, hopefully, a completely fixed transform tool, and some improvements in the filter dialog (that I plan to remove for 2.0, who likes to preview the result on a 100 by 100 image while owning a 1280 by 1024 screen, or even more for some of the lucky guys around).

Since I saw dynamic brush in Corel Painter, I have been willing to get something similar to Krita. Basically, it's a paint op which gives the user control over all the parameters (size, orientation, colors etc) of the brush, depending on the input (pressure, time...), the information used for controlling those parameters are what I call "programs". More simple paint op as you can find in current stable version of Krita offers a much more limited selection of parameters.

There is something else I want to provide with the dynamic paintop, until now, Krita's paint op are using what we call potatoes stamps, for each stroke, some sort of mask is put on front of the canvas, and the color is updated according to the transparency, that works pretty well to simulate a pen, or a single bristle, but not a realistic paintbrush. So something, I am playing with in the dynamic paintop is simulation of bristles.

Krita support scripts (in python and ruby) since 1.5 thanks to kross, but one things that was really missing (beside performance) was tighter integration with Krita, I mean, in 1.5/1.6, there is a docker with a list of scripts, and you click and it does 'something', but what I want is the ability to write filters, tools or anything else like in C++ but in Ruby (or in python if you really have to). The anything else part is mostly done if you use some Qt4 bindings, for instance it's already possible to write a new docker in Ruby/Python and it will behave like a C++ plugin (I should try to write a color selector in ruby just for the fun of it). And now, it's possible to write a filter which will appear like any other filter in Krita's filter menu.

At the end of last week, I have released version 0.5 of Kalculus, my front-end to some mathematical tools.

The new version includes quiet a lot of improvements, notably support for octave and gsl (through the ruby binding), an help browser and the possibility to add comment in the calculation sheet.

For those interesting, you can download it from