I had to reread Bulia’s email three times. It was one of those nigh-mythical events that you read happens in Open Source projects, but never see in person. Yet, amazingly, here it was, and I knew Fred’s patch would instantly double Inkscape‘s utility.
Scalable Vector Graphics and the Open Source Community
Inkscape is a program for viewing, making, and editing two-dimensional vector drawings. This is different from “raster” drawing, as in MS Paint, Photoshop, or The GIMP. In those tools you’re essentially just “painting” destructively on a canvas. By “vector” drawing I mean that when you create a shape like a rectangle, it retains its identity. You can easily go back and resize it, change its color, or move it around without disturbing the rest of the drawing. Vector drawing is what you’d be doing in Illustrator, Corel Draw, Freehand, Dia, Visio or even PowerPoint.
There have been a number of popular Open Source vector graphics tools such as tgif, idraw, Sketch, and xfig, but one of Inkscape’s distinguishing features is that it stores its drawings in a web-friendly XML format — SVG. SVG, an acronym for “Scalable Vector Graphics”, is a W3C standard that is gaining support worldwide, in proprietary and public software alike.
The Open Source community is now adopting the SVG format for everything from desktop icons and company logos to web page animation and artistic Illustration. Inkscape (by way of Lauris Kaplinski’s popular Sodipodi project) is derived from Gill, one of the first Open Source SVG editors, and so follows a long history of serving the SVG needs of the community.
In the five years since Raph Levien began work on Gill, a huge range of features and capabilities had been added to the codebase. Node editing, alpha blended gradients, object alignment, text handling, localization and more had augmented the basic underlying drawing capabilities to make the tool potentially useful for real drawing work. However, there was one glaring omission for which we and scores of users had been seeking a remedy…
The Contribution of Boolean Operations to Inkscape
I read the email again just to be sure.
“I’ve been sent a new patch that implements boolean operations…
The license is public domain. It’s been uploaded to the patch tracker.” — Bulia, November 2003
This was very cool. Boolean operations are a way of taking two shapes and combining them together in various ways to create a single resultant shape. Users of Adobe Illustrator might recognize them in the “Pathfinder”. The four basic operations are Union, Difference, Intersection, and Exclusion. It’s an absolute requirement for creating any artistically sophisticated drawing, and its lack had held the tool back.
Once before, someone had contributed a patch to add boolean operations, but that patch relied on a polygon clipping library provided under an incompatible license. There’s little more frustrating than having a solution in hand, only to be hamstrung by legal problems. Even though it was an important feature for us, we regretfully postponed development of it into the distant future on our roadmap and proceeded with other work.
Here in my inbox, unsolicited and totally unexpected, was the answer. We quickly double-checked that the licensing was clean, that the code was the author’s original work, and that it indeed implemented the feature as promised; it passed on all counts. Fred’s boolean patch had arrived right as we were releasing Inkscape 0.36, so as soon as that release was out the door we merged his patch and started working with it.
Following our policy to “Patch first, ask questions later”, we integrated the new feature as soon as practical, without wasting time arguing about it on a mailing list. We figure that the best way to evaluate an idea is to code it up and see how it works in practice. A working feature now is better than a perfect implementation that still isn’t done. Along with that, maintaining a low barrier to entry for new developers is vital; we don’t want anyone to give up on contributing out of fear their contributions won’t be accepted.
One of the first areas of focus was to add menu items and keyboard shortcuts for the commands it provides. Mentalguy had just recently finished up a massive redesign of the user interface, and so knew the exact place to slip it in. Likewise, Bulia had been hard at work creating a thorough set of key mappings for giving experienced users fast shortcuts for productivity, and found appropriate keys to map the new commands to. Mentalguy’s attention to menus, coupled with Bulia’s shortcut key work demonstrate the value placed on usability for this tool. Both men are artists at heart, so place great importance on making the tool as useful to real users as they can.
Once the basic functionality and usability of the newly merged booleans code was established, other users started testing the feature in real world situations, and identify and shake out bugs with us.
Meanwhile, the development team turned their own focus deep into the code itself. With Fred’s help, they isolated and repaired lingering quirks and bugs. Our more mathematically inclined developers dug into the algorithms in search of ways to relate them to similar functionality elsewhere in Inkscape. By the time we released 0.37, the booleans code was solid.
Even better, Fred stayed on and worked with us to optimize the code’s performance and derive new and exciting features on the foundation he built — such as commands for offsetting, division, and simplification of paths.
In many Open Source projects, such a windfall would be rare, but Inkscape has been fortunate to receive many major advancements from the contributions of newcomers. This is evident when one has used the program for a bit and notices that beyond just having all the usual drawing capabilities, there’s a huge number of thoughtful-yet-modest behaviors hidden away, that combine to make Inkscape a pleasure to work in. Grid and guideline snapping uses a tunable “gravity” style rather than absolute snapping. Objects can be nudged a pixel at a time, for when you need to get that shape just right. The zooming and auto-scrolling of the canvas are direct results of feedback from users and their ideas of how things “should” work. There is even an XML editor built in, for those power users who like to see exactly what they’re getting; this tool allows direct access to the drawing’s underlying DOM model. SVG is XML, and Inkscape is not ashamed of that fact.
The Future
Work continues strong on Inkscape. A very interesting new feature that will appear in the 0.39 release is clones. Basically, you can create a copy of a given object that inherits its properties, so that if you change the original, the clone is also modified accordingly. As an example, consider creating a flower with eight cloned petals rotated around the flower’s center; tweaking the original petal causes all the cloned petals to similarly change. This feature actually comes straight from the SVG spec, so is a capability required for SVG compliance, but nobody knows of any other drawing apps that have a drawing operation quite like this.
Another feature still in progress is ECMAScript (better known as Javascript), currently being developed on a branch from the main codebase by Ishmal. This promises to provide document-level scriptability, including simple programmatic animation.
There’s also a new
Open Clip Art Library established to collect and promote SVG clip art for use in any of the open source drawing tools, and we hope to build in Inkscape strong support for browsing and using this library.
The latest contribution that I think will have widespread and exciting ramification’s was brought to Inkscape quite out of the blue by Mike Hearn. Mike’s project, called AutoPackage, seeks to solve the perennial problem of easily installing software on Linux. It wrappers the underlying RPM, Debian, etc. systems with a friendly GUI front end, similar to what’s used on Windows. Mike’s hoping Inkscape can help be a good proof of concept for his work, and we’re looking forward to gaining an extremely easy installation mechanism for non-technical users.
I know how rare it is for a project to get very much outside participation, and it emphasizes just how remarkable and invaluable each of these contributions are. To me, this type of sharing is what makes Open Source so cool. Fred’s Booleans patch was the first of many such contributions for Inkscape. And who knows what surprise new feature will show up in our mailing boxes tomorrow!
About the Author
Bryce Harrington is a founder of the Inkscape project, and a long time open source developer. Professionally, he’s a senior performance engineer at the Open Source Development Labs. He wishes to give thanks to all the ‘scapers who lent an eye to reviewing and contributing to this article.
I agree this is a good thing. Combine the capabilitiex of Inkscape and Scribus makes for an interesting combination. Throw in Gimp2, even better.
Soon we’ll be able to do ( http://www.deerring.com/ ) this under linux.
It’s very easy to use, but at the same time, very powerful. I enjoyed working with it. I wasn’t an Illustrator user before hand, but working with Inkscape was easy. Now, my GF, who uses Illustrator at work still prefers Illustrator, but even she was impressed with Inkscape, and was mentioning that she found it pretty easy to pick up, considering she already knew Illustrator.
but doesn’t hold a candle to Illustrator, Freehand, or even Corel Draw yet. In particular, it’s text over path tools aren’t up to par with commercial vector packages.
But hey, the price is right!
<quote>but doesn’t hold a candle to Illustrator, Freehand, or even Corel Draw</quote>
hmm..
this is the fourth release, not the twenty fourth.
You may be insterested in the Request Features link on the inkscape website to request any features you want.
For me, Inkscape is really easy to use and fun. The recent menu and dialog reorganization in CVS makes it even easier to use. I can’t wait for 0.39!
I really enjoy these “behind the scenes” / “how we manage our project, what we learned” articles. I’d like to see more of them.
The mentioned clones in the article have been around in Flash since forever… Nothing new there (except Flash doesn’t care about SVG, nor is it open-source), and one has to wonder why SVG-exporting app’s haven’t implemented this ‘standard’ SVG option (apparently)… It’s useful as h*ll…
Sodipodi is open source and has done this for a long time…
http://www.sodipodi.com/
FYI, Inkscape is a fork of Sodipodi if I remember correctly.
Ok, and then you read http://www.inkscape.org/faq.php and you’ll see the connection between Sodipodi and Inkspace…
FYI, Inkscape is a fork of Sodipodi, hence the similarities.
I’ve used Sodipodi and Inkscape, and I have to say I like inkscape more, especially with its ability to perform boolean ops on geometry, which sodipodi can’t do (at least last time I used it, it couldn’t).
Here’s some stuff I made with inkscape:
http://dugnet.com/klown/wallpaper/show.php?id=_wallpaper/_linux/clo…
http://dugnet.com/klown/wallpaper/show.php?id=_wallpaper/_other/the…
Just a small correction: Autopackage doesn’t wrap RPM or DPKG, it provides its own (very simplistic but fully functional) package mechanism. It is a post-1.0 planned feature to also install packages into the system’s native package database.
I have been an Illustrator user for years, and while Inkscape isn’t there yet, it’s gonna be.
There are certain aspects of object control that I think are far better in Inkscape than Illustrator. The rounded corner control for rectangles is a perfect example.
The one boolean operation that Inkscape needs that it doesn’t have(yet) is the Division tool in Illustrator. Say, if you have two overlapping objects, they are then split into three separate objects…super useful.
I use Inkscape every day now, and I must say that I am totally impressed by it constantly.
KEEP UP THE GOOD WORK!
You can perform boolean ops on geometry in Sodipodi too.
From the article:
Even better, Fred stayed on and worked with us to optimize the code’s performance and derive new and exciting features on the foundation he built — such as commands for offsetting, division, and simplification of paths.
So, it looks like division is on its way.
3D objects, that wpuld be cool, 3d text, cubes, etc.
screenshots 🙂
http://andy.fitzsimon.com.au/screenshot-6.png“ Screenshot one
http://andy.fitzsimon.com.au/screenshot-8.png“ Screenshot two
I just tried the latest versions *and* a recent binary CVS version for both Linux and Windows. The thing is SLOW. Exremely SLOW. Especially the Windows version (and the GTK+ interface is just not optimized on Windows, I can see the widgets drawing one by one — it’s terrible).
I suggest you sit down and do some optimizations to your engine and maybe give a hand to the GTK+ people too, before you add any new features on your app. That’s my honest opinion.
“but doesn’t hold a candle to Illustrator, Freehand, or even Corel Draw yet. In particular, it’s text over path tools aren’t up to par with commercial vector packages.”
There is something sad about the laborious re-invention of the wheel for each new platform. So far as I can tell this program does (nicely) what Pro Draw did (nicely) on the Amiga 12 years ago.
I look forward to when Linux has caught up with other platforms and we see some programs that are not just repeats.
This is not a criticism of the coders of Inkscape – the program is obviously needed. But what a pity Java didn’t work – there should by now be dozens of totally cross-platform programs coded in Java.
I’m not sure what is wrong with your setup, but I’ve been very impressed with the performance of Inkscape on both Linux and Windows. In fact, I couldn’t even use Illustrator on a machine with only 256MB of RAM to do simple operations, but Inkscape handled everything very well. Even doing things it isn’t meant to do (like Desktop Publishing – by exporting SVG text from Scribus and manipulating in Inkscape) Inkscape has never slowed down on me one bit.
OpenOffice Draw can do everything *I* need with vector graphics. Seems to be a well-kept secret that OODraw is a very powerful graphics package… and you probably already have it installed on your computer!
Still, I like seeing alternatives!
“This is not a criticism of the coders of Inkscape – the program is obviously needed. But what a pity Java didn’t work – there should by now be dozens of totally cross-platform programs coded in Java.”
The pitys not that Java cross-platform clients didn’t take off, but that the mantra of cross-platform coding (irrespective of language) didn’t take off (something about “money” I think)
Also the wheel get’s reinvented because some “don’t want to” port. Not that they can’t. That only leaves two choices. Do without, or write their own.
>I’m not sure what is wrong with your setup…
Brad, there is nothing wrong with my setup. I use a PIII 700 Mhz with 256 MBs of RAM, XP Pro and Fedora Core 2. Inkscape is just *slow* on both Linux and Windows, and especially on Windows, where the GTK+ generally sucks (any gtk+ app on Windows is unbearably slow and with bad redraws).
I don’t know what kind of machine you have, but running on machines that most geeks have (and many corporations still use), Inkscape feels slow, both on its vector engine and its GTK+ UI. Try loading “Help/Keys and Mouse” or “Help/About Inkscape”. The first one takes about 40-50 seconds to load on my machine, and the second one loads the images in patches instead of all of it on the same time, using ugly black redraws. Ugly and slow!
Java hasn’t “failed”, exactly… it just hasn’t taken the world by storm. Then again, neither did C++ (which Inkscape is written in). The work being done in GNU Classpath, GCJ, Kaffe, SableVM and the other Open Source projects to implement the Java specs and APIs give me hope.
As for reinventing the wheel, that’s the fault of closed source software. If Illustrator, Freehand, Corel Draw, or even Pro Draw had chosen to open their sources up, then we could have reused *their* wheels (the way Sodipodi used Gill and Inkscape used Sodipodi).
From now on, when someone wants to take a vector illustrator in an innovative direction, they only have to start from scratch if they don’t like ths license. That’s why (in my opinion) Open Source Software will eventually kill off closed source software: OSS can radiate faster and fill more speialized niches. The only advantage that closed source has is that they started earlier, and had better funding initially. OSS has had to build up its network effect, but now we’re on the steep part of the asymptotic growth pattern. We’re only going to keep accelerating.
I am running v. 0.38 on a pIII 600mhz (kernel 2.6) and its lighting fast. Somehing must be wrong with your setup.
Try it on Windows first, and THEN tell me that it’s “lightning fast”. Try the latest binary build (.zip) and load the menus I mention above: http://troi.titan-aeu.com/~rjamison/inkscape/builds/
This binary is the one I tried in specific:
http://troi.titan-aeu.com/~rjamison/inkscape/builds/Inkscape0406020…
I like Inkscape alot and I really like the fact that it is a crossplatform application that I can run on Windows as well. It is much easier to use than Sodipodi and it just works great. Thanks to the developers.
What makes you think using a snapshot fullfits your desires better over a stable* version? Why don’t you use one of the stable* versions? At least test it when the snapshot ain’t working properly?
Here’s what i saw on the index.html of that directory: inkscape-0.37-2.win3..> 15-Feb-2004 00:51 6.9M
inkscape-0.38.1-1.wi..> 10-Apr-2004 11:01 8.7M. Why not use either of these?
IMO, if you do not wish to report/investigate a bug in a snapshot/unstable version, don’t bother using it. Stick to stable. Repeat.
*: stable is a bit more relative than normally, since all the Win32 builds are marked as “test builds”
PS: Not every person is able to test Win32 versions…
Yes, a few others have reported some performance problems on Windows. A lot of Windows users have been quite happy with it, though, so it may be something you can fix.
It’s possible that the windows binaries are compiled with debug information (I don’t remember offhand), which tends to have a significant impact on Inkscape’s performance; try the 0.38 release and compare performance between them.
Someone suggested the Windows Gtk port may be to blame, so that might be worth looking at if you’re really curious. I don’t know much details about this, but we’ve had problems reported with it in other areas so it’s definitely a possibility.
Also, note that the tutorials tend to push Inkscape’s
performance envelope in general, so machines that are a bit stressed on memory somethings show the sluggish behavior you’re noticing. Often Inkscape will work fine for more “ordinary” sized documents.
Anyway, if you are able to narrow in on the cause of the performance problem, and report what you find through the bug tracker or mailing list, it may help identify a way to optimize the performance for the next release.
Thanks,
Bryce
Actually, the snapshot versions are well worth trying out. A lot of new capabilities have gone into the codebase since the last release so you get more functionality. Plus, if you run into problems and report them, this helps ensure that the next release is that much better. Of course, don’t expect that the snapshots are going to be as stable or performant as the releases, since we do extra QA for the releases and since bugs do tend to slip in during the development process, and that you should plan on reporting problems you run into.
Bryce
I don’t know what kind of machine you have, but running on machines that most geeks have (and many corporations still use), Inkscape feels slow, both on its vector engine and its GTK+ UI. Try loading “Help/Keys and Mouse” or “Help/About Inkscape”. The first one takes about 40-50 seconds to load on my machine, and the second one loads the images in patches instead of all of it on the same time, using ugly black redraws. Ugly and slow!
I am running v. 0.38 on a pIII 600mhz (kernel 2.6) and its lighting fast. Somehing must be wrong with your setup.
I have a 700Mhz PIII with 256MB of RAM also. I generally don’t have a problem using inkscape but Jon has a point, to a degree. Loading the “about” section is kinda ugly but it only takes a second or two at the most. The “keys and mouse” help section is bad though. It took a full 9 seconds to load on my machine. That’s nowhere near the 40-50 seconds that Jon claims but it is still unacceptable.
sodipodi is crap, inkscape is rad.
sodipodi has just an alienating interface and tries to tick of users by not bringing in any usability fixes. inkscape is at least hard working to make the color selector which is yet a pain to use, at least more comfortable to work with. i bet in a year, the two apps will have drifted apart tremendously. while sodipodi is being worked on by 3-4 people due to the obscure codebase no sane person understands, lack of documentation and api – well they just dug their own grave
> It took a full 9 seconds to load on my machine.
The keys.svg took 37 full seconds to load on my dual Celeron 2×533 with XP Pro and 256 MB RAM. I also find it very slow and I would request some optimizations.
Even when creating my own simple shapes I found it to have slow redraws. For example, I did a star and tried to move it on my working area and it had visible redraws. No wonder the much more complex keys.svg is unusable…
And one feature request: Please make it so the vertical toolbar can be placed above the horizontal one and/or next to each other. I am on 1600×1200 and putting them next to each other would work better for me to save some space.
Also, all the dialogs need HIG-love, currently they do not adhere to the HIG at all. There are many dialogs with all the widgets glued to other widgets (HIG requires 8 to 12 pixels between every element from any other element, including the borders of a window).
I just compiled Inkscape-CVS on my Slackware and it loaded keys.svg in 9 seconds too. However, this is an AthlonXP 1600+ machine with 512 MB of RAM. While it was loading it, the whole window was unrefreshed and was looking like dead. A spinning cursor should have being better with the window fully refreshed on the background — or optimize the engine more so it loads faster.
And one more request: please upgrade to libsigc++ 2.0, I had that installed on my slackware, but not the 1.2 version that ./configure asked me for.
…it’s pretty cool, and quite fast on my Athlon 900/1GB Ram.
Some of the features still missing to make it a true Illustrator contender, for my part, are fill patterns and brush strokes. There is a calligraphy tool but so far I’ve only seen a single “brush”…
But I’m definitely going to play with it some more.
I read someplace that Inkscape was a fork from Sodipodi but it did not say why.
Articles about SVG often post results as jpg’s, gif’s or png’s rather than the real thing. That’s not the case with Flash and shouldn’t be the case with SVG either. Adobe’s SVG viewer is no more difficult to install than Macromedia’s Flash player.
Every other page on the web now has a Flash but I seldom see an SVG without searching. And understandably – because, allthough SVG can do as fine a job as Flash for stills amd take up no more space than png’s then it lags severely when it comes to animation.
An example (Adobe’s SVG viewer required)
http://www.carto.net/papers/svg/samples/progressive_drawing/krokus….
Another one with a little animation
http://www.xmluk.org/slides/RAL_2001/Duce/xmluk1/xmluk_ral_interact…
I prefer Inkscape because its layout is easier to understand and easier to follow, Sodipodi has good performance and their is no technical reasons I dislike Sodipodi other than usability issues.
There is something wrong with the way win32 redraws windows and UI-Elements.
Other Popular Crossplatform-UI Toolkits like FLTK or the FOX-Toolkit fixed this win32 design-issue by introducing evil workarounds and other neccesary quirks. But since Gtk is primarily targeted at a X11 Environment, nobody fixed it on win32 yet.
BTW. Work is being done to provide a decent win32 implementation of gtk: http://gtk-wimp.sourceforge.net/
>BTW. Work is being done to provide a decent win32 implementation of gtk:
That’s just a gtk theme (red lipstick on top of an ugly woman), it has nothing to do with the underpinnings of GTK+ that need FIXING on Windows.
The biggest thing I see holding SVG back is a lack of a good OSS browser plugin for it. If you look at what Adobe’s or Corel’s can do it’s amazing. zoomable maps with links, animated office plans, real time graphs from data, and those are just the sample files…they can make beautiful animations that are pure scripting and have the client side do all of the heavy lifting…server side is no worse than generic PHP.
The only tools that make or display that level of SVG are their own tools….SVG has been around for years!!!! if these guys want to see it grow they’re going to have to get involved on the browser/client end also. A brower that could handle SVG without plugins would be way cool [lay out page graphics with no jpegs or gifs at all!]…you’d be able to do all sorts of cool stuff [sure you can use scripting now, but with SVG properly, it could all be CSS & XHTML]…of course it’d pretty much be alone because nobody else does that yet.
Well, last I checked. There was only one working on it. The OSS world needs a bit more “looking over the shoulder”. The work the scribus people are doing on PDF is impressive. The work that everyone’s doing on SVG (from Batik on down to Gnome) needs to be closer knit. The work that the people are doing on SWF needs to be brought in, as well as what Cairo is doing. Doing your own thing is nice, but sometimes collaboration and extensive sharing is even better, especially when working on something complicated.
> > BTW. Work is being done to provide a decent win32
> > implementation of gtk:
> That’s just a gtk theme (red lipstick on top of an ugly
> woman), it has nothing to do with the underpinnings of
> GTK+ that need FIXING on Windows.
I know, but at least they’re trying. Maybe they’ll fix this issue too if someone asks nicely.
.. I like Sodipodi’s interface better. I understand that it’s confusing to work with for people who don’t use the programme all that much, but, speaking as someone who has spent a lot of time in Sodipodi, it’s wonderful. Most actions are only a mouse click away.
I understand that people have put a lot of effort into the new Inkscape interface, and it certainly seems friendlier and less eccentric. I just object to people who characterise Sodipodi’s interface as ‘hard to use’ or ‘not user-friendly’, as I suspect it is the result of quite a bit of thought.
As a person who worked on Inkscape UI, I disagree that Sodipodi’s interface “is the result of quite a bit of thought”. Just one example: until well after the fork, Sodipodi was unable to save its preferences. Those precious few options it allowed you to set were lost when you quit and had to be set again next time. The funny thing is, almost all code for saving was in place, it just was not enabled in a couple places. And enable it was one the first things we did in Inkscape. There are many more examples where Sodipodi showed utter negligence towards usability – not the “our way is better” sort of thing, but simply “nobody ever thought about that.”
> And one feature request: Please make it so the vertical toolbar can be placed above the horizontal one and/or next to each other.
We cannot yet make horizontal toolbar vertical or vice versa, but in CVS version, you can simply hide any of the toolbars.
> There are many dialogs with all the widgets glued to other widgets (HIG requires 8 to 12 pixels between every element from any other element, including the borders of a window).
I agree many of our dialogs are ugly, and we’re working on that. However this particular suggestion is hardly acceptable. HIG allows some deviations from its recommendations when there’s a good reason, and we do have a good reason to not blow up our dialogs which are quite huge already and hard to work with on smaller screens (we had users complain about that). Things like reorganizing, rearranging, condensing help, but every pixel counts when you’re working on graphic. Note that most commercial graphic tools use their own small and tightly packed non-standard widgets. We are not going to use our own widgets, but at least we’re trying to make our dialogs look professional, stylish, and compact.
I have seen small dialogs that fit perfectly on small screens, and they are not HIG-ified. At least for those, you need to clean them up.
here’s where i go slightly off-topic…
Michiel, no, you are not the only one who prefers Sodipodi’s interface.
[rant style=”polemic”]
I just can’t understand this pervasive and morbid love of parent-child windows and horizontal menus. The various window managers and apps that follow this UI model had the chance to create something more productive but they BLEW IT. What could be more CONVENIENT and USER-FRIENDLY than having your menu UNDER YOUR MOUSE, wherever it may be at the moment? Even better than the Mac’s constant menubar (and I’m primarily a Mac user)! It’s like when i hear people complain about the GIMP’s (pre-2.x) interface: “there’s no horizontal menu in the window! I’m confused.” Obviously, a question of UI “familiarity” and NOT of “improvement” (not that the model Sodipodi uses is something new either).
[/rant]
…Thank you. Back to our regularly scheduled program…