What a single bug report can do

Some bugs can last for a very long time. One of these bugs was bug 119150, it was added in 2005 and resisted several attempts to fix it. Additionally it was the last reported Karbon SVG bug, which motivated me to start a new attempt to fix it.

Karbon before the fix

Fixing file import bugs is quite similar to archaeology, as you are digging through lots of data searching for some small detail that breaks the import. I was able to fix a smaller bug in the unit parsing which improved the import a bit. After investigating further I discovered that the style of groups in a defs element wasn’t correctly used, but I wasn’t able to fix it. So I filled a bug about it with a small testcase, which Jan could fix the same evening. Even after fixing the second bug the file wasn’t imported correctly, so I continued to search for the next bug. It turned out that the stlye of the use element wasn’t used. I wrote a provisorily fix which had some side effects. I send it to Jan, who was able to correctly fix it the day after.

Finally tuesday evening there was the magical moment were the file loaded perfectly for the first time and I could close the bug report after 1111 days.

Karbon after the fix

To summarize: Due to the nice teamwork and the amzingly fast bug fixing by Jan, we were able to fix three SVG import bugs in 36 hours and could close the last reported SVG bug. There are now only 11 reported Karbon bugs (without the PS/EPS bugs, only three bugs).

Karbon now needs a lot more testing and there haven’t been many bug reports in the last time. For example you could open any .odg you have with Karbon and check if it looks correct. As the odf code is shared across KOffice, any bugfix will improve the situation for all apps.


18 Responses to “What a single bug report can do”

  1. dd Says:

    what do you think of fuzzing? it could detect more bugs and stabilisation issues..

  2. Elvis Stansvik Says:

    Kickass! Keep up the good work!

  3. slangkamp Says:

    @dd: Yes, it would be interesting to see how Karbon works on fuzzied files. I don’t know if there are any free SVG/XML fuzzing tools. It would be great if we had an automated test using fuzzing on oxygen or openclipart svgs.

  4. dd Says:

    yeah, i write it already in the kde-forum (http://forum.kde.org/more-stable-apps-through-using-fuzzing-tools-t-26560.html ; sadly, no response, yet :/)
    i think that there are some interesting tools such as this jpeg-fuzzer (http://www.securiteam.com/tools/6P00B1FNFM.html). for me, it’s a possibilty to harden and to stabalize several apps, such as plasma or koffice. but i’m not a developer…

  5. dd Says:

    ah by the way, there are lots of xml-fuzzer:

  6. finto Says:

    One thing I always think about when I read about art in kde is that the artists always mention Inkscape as their favourite tool and I have never heard one of them mention karbon. I think they could be an amazing source of input for the karbon developers. Have you ever get in touch with the artists?

  7. slangkamp Says:

    @finto: The artists use Inkscape because they need certain features like blur that Karbon currently doesn’t support. We are communicating with the artists and get important information about different features and ui design like the color chooser.

  8. finto Says:

    cool…thanx for clarifying my doubt. I was quite naive but at least now I got some insights 🙂 keep up the good work with karbon!

  9. Frédéric Julian Says:

    Good job 😉 I think that Karbon is the most stable application of KOffice2.

    By the way, if you still need some “relatively” simple SVGs which are not well rendered with the beta5, I can help you, I know somes 😉


    Otherwise, maybe you can help me, during my tests, i didn’t find where I can change the size of the shape’s contour line?

  10. Dread Knight Says:

    Karbon should cut the crap and just be part of Krita.
    So much more power when combining things on the same canvas.

    FFS… photoshop even imports 3d models… at least krita could take care of both 2d raster and vectorial.

  11. slangkamp Says:

    Adobe still offers Illustrator, even if Photoshop can handle vector graphics. Karbon offers more functions for vector graphics like effects etc. If you don’t want to use two different apps, just use Krita.

  12. slangkamp Says:

    @Frédéric Julian: Thanks. The stroke width can be changed with Stroke Properties Docker. If you don’t see it, it can be shown with Settings->Docker->Stroke Properties.

  13. Frédéric Julian Says:

    Thanks too ! For the stroke, I just believed that it will be displayed automaticaly when I select a shape.

  14. slangkamp Says:

    @Frédéric Julian: We have fixed the bug, where some some wrong strokes appeared in both svgz files. Additionally we partially fixed the Amarok logo, but there are some unsupported SVG 1.2 elements in it.

  15. Frédéric Julian Says:

    Woohh… Was it already fixed in the trunk when I pointed out theses bugs? Otherwise, I’m impressed by your reactivity.

  16. slangkamp Says:

    No, we started to fix the bugs after you posted them here. Sometimes we can fix these bugs pretty fast and that’s why we need a lot more bug reports.

  17. Frédéric Julian Says:

    Ok, so I continue 😉


    I use a lot the feGaussianBlur filter. Which is SVG 1.1 compliant, but not rendered in the beta5. I don’t know if it’s a bug, I guess you still don’t support all the 1.1 standard and you already know this, but I can ask.

    In all case, just another question: when you improve the svg support in Karbon, do you also improve the svg support in Gwenview/Dolphin/Konqueror etc… ? I think the code is shared. If so, where is the best place to report bugs? And, if the svg support is centralized in KDE, do you think that it will be possible, in the futur, to merge the code with the one of Qt (after their new openness)?

    I ask because I like to use SVGs in my Qt apps. I have notably an app where the user can add SVGs (http://hevea.tuxfamily.org/), but I think that the SVG support in Qt is worse than the one in KDE.

  18. slangkamp Says:

    Yes, filters are missing. We know that blur is one of the most important features at Karbon is currently missing, but that’s a very big task and can’t be done for 2.0. Implementing full SVG 1.1 support with filters, animations etc. is really are hard task and will take a long time.

    The SVG code isn’t shared between KOffice and the rest of KDE. KOffice couldn’t use the KDE code as we have different requirements like the ability to edit.
    QtSVG supports SVG 1.2 Tiny, which doesn’t include filters.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: