TeamInterview046

Interview with the team on Inkscape 0.46

With almost 50 contributors out of 111 registered at SourceForge, and even more, if you count those who just sent a patch via patches tracker, it's no really possible to talk to everyone who participated at the preparation of the shiny new Inkscape 0.46 release.

Here is an interview with several Google Summer of Code 2007 students and several Inkscape developers.

Maximilian Albert

Info: Heidelberg, Germany. Aiming for a "Diplom" degree in mathematics (currently in the middle of his final examinations), singing in various choirs & vocal groups and coding for Inkscape.

When you started 3D box tool, did you have in mind just drawing a 3D box or did you think about it as of first step to functionality like extrusion?

I certainly also had extrusion in mind, as well as a couple of other things (in particular, I would have loved if the opportunity had arisen to include more "geometric" functionality; see the link below). You may want to have a look at the original proposal, especially at the section "further ideas":

http://www.rzuser.uni-heidelberg.de/~malbert/

And never mind that with hindsight the proposal turned out too ambitious :-/ Unfortunately the internal refactoring of the tool that was necessary after the end of SoC has kept me from completing a lot of these things in the meantime. Since I'm in the middle of my final examinations right now and do not yet know what will come afterwards, I'm not sure when I will get to resuming my work on it (other than providing a couple of improvements here and there). But hope dies last :)

The good news is that the refactoring has brought extrusion very much within reach. It was only after SoC that I truly discovered lib2geom, but while playing around with it, it was only a matter of one night's work to produce a kind of LPE which draws a given arbitrary shape in a certain perspective :) However, integrating this into Inkscape itself will still be a challenge and require a lot of work (especially on the UI side). But the first attempts look promising.

While extrusion looks like natural next step, what more could be done based on current code?

Well, the above-mentioned draw-a-path-in-perspective thingy (which is actually tightly connected to extrusion) is definitely one thing that could and should be done. I believe that 3D box-based grids would also prove rather easy to do.

Other than that, most things are likely to require a good deal of more infrastructure or interoperability with other parts of the code, and I don't have a concrete idea in mind what would be most natural thing to do. Of course, there also remains a huge deal to improve about the tool itself, its features and user-friendliness, so there probably won't be time to tackle great new tasks in the near future anyway.

Johan Engelen

Info: Enschede, The Netherlands. Working on tiny electrical machines for his PhD, playing guitar, drums and sax, and working on Inkscape 1.0.

Live Path Effects definitely bring Inkscape to a new level of flexibility. Could you please explain in few words how they "tick"?

Basically, Inkscape stores the original path in an "inkscape:original-d" attribute of a path. When it encounters such an attribute, it applies the effect refered to in the "inkscape:path-effect" attribute and outputs the result to the SVG "d" attribute. This way, LPE is 100% valid SVG and the result should look the same in all SVG viewers. Inkscape sees the "inkscape:original-d" attribute, but viewers and other editors will just ignore it and use the normal SVG "d" attribute.

"inkscape:original-d" => LPE calculation => "d"

Because the original path data is stored, Inkscape can perform node editing on it and recalculate the effect (and the result is again stored in the "d" attribute).

Most effects will need parameters to modify their behavior. Those parameters are stored in the <defs> section of the SVG file. Probably it is best to start Inkscape, apply an effect and see what the SVG looks like in the XML Editor!

The mathematics is done using lib2geom, or 2geom as we call it. Although this library is still in Alpha phase, it is already very powerful and greatly simplifies the programming effort on path data. This helped me a lot in writing the LPEs and it would have been much harder without it. We are planning on rewriting most of Inkscape to use 2geom functions.

Can new live effects easily be plugged into Inkscape?

One of the goals of my GSoC project was to make a framework for LPEs, so that developers can easily add new effects, without knowing much of the internals of Inkscape. Although all LPEs in 0.46 are written by me, I think I have succeeded in that goal: already 3 new LPEs have been added to Inkscape's codebase (personal favorite: a 'sketch' effect)

Right now, Live Path Effects are built into the Inkscape executable, unlike the Python extensions. So it is not possible to, say, download a new effect from internet and use it in Inkscape. In the future, I intend to work on a plug-in system for LPEs, that would enable this downloading of new effects.

What great new effects could be done using LPE?

At the moment we already have a couple of powerful LPEs in Inkscape, displaying the possibilities. Live boolean operations could also be done with LPE.

Right now, I am mentoring a group of French students who are working on an envelope distortion LPE. When that is working, the next step could be mesh distortion...

Gail Carmichael

Info: Becoming a Master of Computer Science in Ottawa, kicking butt in Taekwon Do, and trying to contribute to Inkscape with what time is left in between.

Text related changes that your GSoC projects brings to codebase in 0.46 are probably not quite user visible. Do they provide some groundwork for future versions? Could you please elaborate on that a little?

It is true that a lot of my work isn't as obvious or exciting to users as, say, the new 3D box tool. But that's exactly why the text tool can be so easily neglected, and one reason I wanted to jump on board with it and work on some improvements for the Summer of Code.

The two areas that I worked on last summer included adding support for the <tref> element and adding a new font specification attribute to text elements. Thanks to the latter project, users will no longer be frustrated with duplicate or unselectable font choices in the font dialog. This also laid the groundwork for being able to change how we list the font families and styles in the dialog (that is, we can separate the names from the styles however we wish), and to support fonts that CSS can't describe. Hopefully I will be able to see this extra work through some day.

You had two internships in Corel before entering GSoC in 2007. How exactly different does it feel to work/research for an open source project? :)

It's a whole new experience to work with a team you can't see or talk to in person. (Though I was fortunate enough to meet a few key Inkscapers at the LGM in Montreal before the summer coding began.) The freedom you have when working on an open source project is quite nice, because you can work on pretty much whatever you want to. It's also quite interesting to see that all software projects, open source or commercial, can suffer from the same problems. For example, whether you belong to a corporate development team or contribute to an open source project, you are bound to produce bugs. What may differ is how these bugs are reported, triaged, and fixed. In open source, the user community participates in the process much more.

Miklós Erdélyi

Info: Dealing with problems in information retrieval from under his desk and from the Web, while beating piano and computer keyboards. When not quite occupied (in the summer), he likes to relax and do some hopefully serious Inkscape stuff, just for fun.

This is the second time you take part at GSoC for Inkscape. The previous time it was Cairo based exporting to PDF. Looks like you have pretty good impressions of Google Summer of Code, haven't you? :) What's most important thing you learned from participating at the program? Are you planning to do it the third time this year?

Yeah, GSoC is cool since you can get really involved in an open source project and your code can impact thousands of users (besides, you get paid for doing your hobby). The most important thing I learnt from the program was that being able to communicate and get others acquainted with the problems, difficulties you face during development is just almost as important as being able to write good code.

I'm planning to do GSoC for the third time this year. Besides bug fixing, I have some ideas for PDF import improvements like embedded font handling, metadata import, better transparency support. Regarding PDF export and the (yet immature) Cairo-based renderer, there are areas which could be enhanced to pass more tests from the SVG 1.1 Conformance Test Suite, not mentioning the improvements which could be made because of the much better PDF backend available in Cairo compared to what was available at the time the original PDF export extension was written.

You project this year was PDF/AI import. How does your importer treat documents with CMYK colors and colors that are mapped to a particular ICC profile?

At the moment the importer uses Poppler's color space conversion functions to always convert colors encountered in the PDF document to the RGB color space. These parts could be easily changed to support the CMYK color space since CMYK and ICC profile support is already built into Poppler.

Bryce Harrington

Info: Portland, OR. I work at Canonical as the Ubuntu X.org maintainer, enjoy woodworking, and these focus on release coordination for Inkscape.

One sad fact about Inkscape is that it can be dead slow on complex documents. It was proclaimed that 0.47 will undergo a significant refactoring of the code base. Will it be just getting rid of code duplications and the like, or will it also bring various speed/memory optimizations, thread safety etc. to make Inkscape as robust and low-fat as possible?

Rather than performance, 0.47 will be focusing on getting rid of code duplications, correcting style inconsistencies, fixing object referencing issues, organizing source files better, breaking out libraries and sub-packages, continuing more C-to-C++ work, and completing various architectural reworking efforts that have been delayed by other priorities in the past.

In theory, this should greatly help improve our situation with respect to thread safety. Performance improvements will probably be accidental, but hopefully with a cleaner codebase, performance improvements should become more obvious and simpler to do.

However, often performance issues are algorithmic limitations, requiring shifting to different data structures or alternative logic, yet cannot be done due to the quantity of refactoring this would entail. 0.47 would be the ideal time to undertake such work, so I'm hopeful to see some ideas for these kind of improvements on the todo list.

The refactoring will also get us into a better shape for switching out our renderer to Cairo. At that point, we'll be able to leverage the Cairo team to help attain performance boosts on complex documents.

Are there any plans to implement optional use of GPU (e.g. through cairo-glitz)?

Exactly; once we have transitioned fully over to Cairo (post-0.47), this will be an important goal for us. It will take quite a bit of testing and working with the Cairo community to ensure we get maximum benefit of this.

Some Inkscape developers are known to create pet projects that might or might not be used by the core project later. Live Path Effects that entered 0.46 are largely based on 2geom — a library for computational geometry, though its integration was planned rather for 0.47. Can you name other subprojects that are in the queue for further inclusion? Adaptagrams maybe?

A lot of people are excited about the potential 2geom brings. I'm very enthusiastic to see it finish its alpha phase and be released in a form that we can start linking to as a normal dependency. Transitioning fully to 2geom will help remove a lot of core logic from Inkscape into a form that is easier for experts to maintain and optimize.

One of the cool things about Inkscape is having people (often new contributors) bringing these new ideas into the project. Leveraging other people's code is one of the greatest features of being open source.

We've also seen some great work with extensions and LPE's, and in 0.47/0.48 I'm hoping we can see plug-in type features be more formally handled in Inkscape, so that people can develop and install new extensions independently of the main Inkscape releases. This could both stimulate new subprojects, and remove code from the Inkscape core to reduce its weight and better distribute the maintenance efforts.

Inkboard is another sub-project which has received a lot of work but is not yet formally included by default in Inkscape. Unfortunately, it is not being maintained as actively as needed, and it's got a number of critical bugs that makes it difficult to use at the moment; this would be a great project for someone to build a subproject around.

I expect one day we'll also have an animation sub-project. It's a popular feature request. While there's been discussion on the mailing list about it, we're still waiting on some proof of concept implementations of the various ideas and approaches. I think this would be rich and fruitful area for people with ample time and the need for a fun coding challenge to take stabs at.

John Bintz

Info: works and plays in Baltimore, MD. When he's not at his day job as a Web programmer, he's usually doing something comic related (most like working on "A Moment of Clarity," his all-ages comic), and his work on Inkscape is aimed toward making it the best tool for drawing, illustration, and comics. When he's not staring at a computer monitor, he drinks beer and thinks about making comics.

The new and shiny Inkscape 0.46 features a versatile bucket fill tool that traces any closed shape (bitmap or raster) to a path filled with a user defined color. In the past we've already seen Adobe dropping its standalone vectorization tool in favour of Live Trace in CS2. Might it be that Bucket Fill tool will obsolete the potrace-based tracer in the future? Or will the tracer become a interactive tool as well (considering that e.g. its SIOX related part still has room to enhancements)?

Honestly, I don't know. :) My experience with using potrace for bitmap tracing is limited to only what I needed to get the Bucket Fill tool working. The touch-fill functionality of the tool would be perfect for performing SIOX-like selections of areas to trace into appropriately-colored vector objects. I can still see the need for converting an entire imported image to vector in one swipe, say a logo, without needing to switch to a different tool to do so. Also, I don't have enough experience with Live Trace to know just how it operates.

I've seen the first contribution from you in the development tree around autumn 2003, at the very beginning of the project. But you wrote the Bucket Fill tool only last year. Might it mean that Inkscape just has become THE tool for your comics work? :)

Well that first contribution, which fixed a few small UI issues in Sodipodi, was done years before I even thought about doing "A Moment of Clarity," let alone doing the inking and coloring for it in vector. I didn't start using Inkscape seriously for my illustration work until 0.44, when the Calligraphy tool became solid enough for my style of inking, and when layer support was improved. Even then, there were many stability issues that made the drawing process frustrating. Between myself and other Inkscape devs, those issues were fixed in very short order. The Bucket Fill and Tweak tools were the final pieces of the puzzle that gave Inkscape a huge advantage over other drawing tools. Except for scanning in the original pencil artwork in The GIMP, and exporting the Web- and print-ready artwork using ImageMagick, the final comics you see are done entirely in Inkscape.

Now, with the release of 0.46, I feel very comfortable recommending the software to other comic artists who are interested in working in vector and don't like the approach that other vector tools take when it comes to hand-drawn illustration work. I've shown development builds of the software to a few other artists and, with few exceptions, they immediately asked when the final version (0.46) would be out. :)

Ted Gould

Info: Los Angeles, California. I work for Canonical on Ubuntu and enjoy photography, hiking and graphics.

The new version is a major leap to a better support for SVG features thanks to our "filters" and "text" people. What could be the next big thing feature-wise in 0.47? I think I saw a writing on the wall, and it mentioned SVG Fonts for sure... :-)

I try not to predict the "biggest" until the release is frozen, it's amazing what surprises people bring to the table. But if you're talking about SVG features I think the last major feature we need is fonts, so if that gets done for 0.47 it'll be big. But, we're hoping to have a lot of cleanup being the focus for the next little while, so hopefully the biggest features will be more polish and stability.

Raster effects that are available in 0.46 thanks to a GSoC student and ImageMagick (and you :-)) are destructive, while SVG Filters in the very same 0.46 are non-destructive. Do you see a way to unify them in one UI or, at least, make both non-destructive?

I don't like to think of anything as destructive as we still support the full undo buffer and user's data is never lost.

But, as far as effects keeping the original shapes, I would like to see that. I hope that as the live-path-effects can be merged into the extensions system that additional code would allow for keeping data. I doubt that the UIs would be merged between SVG filters and effects, they're doing distinctly different operations, one is changing properties of the renderer while the other is changing the document.

Jon Cruz

Info: A software engineer with professional experience ranging from hand-helds and PDA's through to large scale server systems and infrastructure, doing multimedia, entertainment, set-tops, Linux, security and wireless along the way.

Let me treat you as all-things-color guy in the project :) Inkscape 0.46 has color management, but still lacks usual editing of color swatches. You mentioned before that Agave could be used as external editor of color swatches. What's the most possible way to go in 0.47 and beyond to provide currently missing functionality regarding swatches?

Well, the main difference we're looking at is in trying to target support for all swatches, not just "color swatches". This is similar to how a graphic designer, clothing designer or even home decorator might collect up various things into a "swatch book". So a "swatch" is really a sample of some material, and we would like to take that approach. This is especially so considering that it closer matches how artists work.

What that means for an Inkscape user is that we will try to organize things with a focus on how they are to be used, not on how they are implemented internally. Also this will allow for collecting up colors, gradients, patterns, etc. into individual "swatch books" that can be shared between documents and that many can be open & used at once. So someone doing a web comic might create a separate swatch book for each character so that they can easily manage their workflow and get "Bob's hair" and "bob's shirt" right without having to think too much.

It would also bee good to have these stored externally in an easy to share format. The CREATE group worked out a format for more robust color exchange that I'll be using as a basis for the external color storage. Not all who were working on that had an immediate need for more than just color, but a few have. So I'll be trying to implement something in a standard way that is easy for other applications to support. At the least we will be able to exchange complex colors (spot, registration, CMYK, etc.) and base gradients. GIMP can use a few more options on gradients, but gradients in SVG can be viewed as a subset of those possible in GIMP, so those can be shared. And it would be nice if we could leverage CSS as much as possible in the process so as to keep things even more interchangeable.

So, to sum that up, we will be taking a two-pronged approach. First is a user-visible change to add a nice UI to manage sets of colors, gradients, etc. in a manner that is more natural for artists. Second is to keep things implemented as standard and sharable as possible. Agave, Inkscape, Scribus and GIMP can all benefit from shared resources such as this, and I've been in touch with others from all those projects to try to ensure the community will be able to benefit.

I hear you've been doing some work on better support for input devices? Is it just about graphic tablets like Wacom and Aiptek or some other controllers like Griffin PowerMate too? Could you elaborate please?

The first part will be to support tablets and the like. GTK+ provides a standard cross-platform mechanism to access their capabilities, and we are already using that for the Calligraphy tool. I'm adding more use of that API so that we can present a much nicer UI to manage and configure such devices. Also I'm adding in support for detection of different tools (pen, puck/tablet-mouse, eraser, etc.), to switch Inkscape tools or settings. Coincidentally at the same time someone came up with a patch to add named presets for the Calligraphy tool, which is one thing I was thinking would work nice with the enhanced tablet detection. Also we're going to be adding more access to tie certain actions to certain buttons on tablets, pens, etc. This last feature ties into the non-tablet devices for the second phase...

The second part will be to try to add support for other devices such as the PowerMate, ShuttlExpress, Nulooq, etc. Also MIDI based controllers and others. GIMP has had some support for various devices, so we at least have a model to draw from. The main limitation we have in this area is feedback from people how have such devices. If such people will give feedback and participate in discussions, we can add more support much sooner.

The third part will be to try to take the high-level, artist-centric configuration approach and share things with other applications. This might mean having something that will read settings that GIMP has for devices and merge them into a unified workflow. Or we might get to collaborate with other projects on a more "big picture" way of managing such devices.

bulia byak

Info: a non-programmer from Canada who suddenly found himself in charge of a lot of things in Inkscape.

Once you mentioned that one of the reasons for creating engraver's toolbox in 0.46 was your love for old books illustrations. Did you mean illustration like the ones by Paul Gustave Doré? :)

I wouldn't cite any single name — I'm just enchanted by the style in general. From high art to clumsy kitsch, any old engravings have something that a lot of modern art utterly lacks: a thoroughly handmade feel in every tiny detail. This is what I want to make possible again. Technology has made a lot of things obsolete — but it also has a potential to resurrect them at a new level, and that's what I'm interested in.

However stupid the current copyright laws may be, they have one unintended positive side effect: they force us to look closer at the old stuff which has by now reached the safe harbor of public domain. I think Encyclopedia Britannica's 1911 edition has had more keen readers than any of the subsequent editions, due to its reuse in Wikipedia. The same thing is at work for graphics: a lot of clip art these days is scans from century-old publications, and most of these scans are black-and-white engravings. So this visual style is suddenly relevant again, but we cannot live off the old stock forever — we need modern tools that would allow us to continue and develop the old technique. I want Inkscape to become one of such tools.

What further changes to the toolbox do you envision?

As for my future plans, time and resource permitting, I definitely want to expand this functionality, make it more robust and add features. I'm looking in two directions at once: I want it to be more automatic in the way it is done, yet at the same time less automatic — more handmade — in the way it looks. How far I will be able to go in these directions is hard to say, but I do have ideas to explore.

From what I remember, being one of key developers, you are also end-user of Inkscape. Is it the main drive behind your contributions?

Of course. I have always wanted to have a vector editor that does what I want in the way I want. That's what led me to Inkscape and what keeps me in the project to this day.

---

Interviewed by Alexandre Prokoudine