Introduction To Inkscape And Its Future

WarriorC writes "Bryce Harrington, Inkscape's founder, wrote an article introducing his brainchild and where its development is heading (see: Illustrator-killer). Some screenshots of the latest CVS version are included." It's also a nice glimpse into an "unorganized" but nonetheless successful open source process.

Comments

Trivial?

[th1ckasabr1ck]

"...one of Inkscape's distinguishing features is that it stores its drawings in a web-friendly XML format"

Isn't that a fairly easy change to make to current open-source vector-drawing utilities? Serializing the output to XML instead of a binary format doesn't seem like the first feature you should mention when describing the advantages your program has over others... Then again, it is open source.

This bothers me

[stratjakt]

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

The patch in question, a boolean operations patch, is said to be PD in the article. But this attitude is a major landmine for GPL (or any other free license) projects.

At least Linus wants folks signing patches now. But how much damage has been done to the various Free projects we all rely on? How can anyone guarantee the pedigree of any of the code on my linux box with a "go ahead and paste it in!!" attitude?

Anyhow, I call this Kinkscape since I use KDE. You may know it as Ginkscape.

Re:This bothers me

[schemanista]

The SCO fiasco crap could have easily ended if Linus could produce some sort of audit trail, send it to SCO, and say "here's who contributed what, go take it up with the author".

Linus did say that.

"It's not our side that isn't identifying the code. We'll work damn hard to identify everything they care to name," Torvalds said. "In fact, the source control system is out there in the public, and it identifies the source and the reason for patches," mentioning the BitKeeper repository he's used for the past two years to keep track of code in the heart, or kernel, of Linux

...

No. I allege that SCO is full of it, and that the Linux process is already the most transparent process in the whole industry. Let's face it, nobody else even comes close to being as good at showing the evolution and source of every single line of code out there. The only party that has had serious problems clarifying what they are talking about is SCO, and now when details start emerging like with RCU, it's clearly about IP that they had nothing to do with, and don't even own. I'm sure that they are confident that they own the collective work of Unix, but that's a separate thing entirely legally from being the actual copyright owner of any specific section of code.

How much more of an audit trail do you want? The SCO-job was gonna happen. One way or another.

Re:What makes this a killer?

[quinto2000]

Gimp actually has a fairly closed development structure, and I don't think it would be accurate to say that they're trying to steal Photoshop's userbase. They seem to have their own goals and interests, and seem to be pretty stubborn about them (especially interface decisions).

I need it

[InternationalCow]

Apart from showing nicely how the "hive" model of software development can and *will* work (although I am not sure whether patch first, ask later is always a good idea), this development has me hoping that people who, like our group, use Illustrator and Photoshop for scientific illustrations, can finally escape vendor lock-in. For relatively simple illustrations (we always keep illustrations as simple as possible for reasons of clarity), Adobe's solutions are really overpriced. Licensing issues have us worried anyway since it is almost impossible to keep track of all the licenses we're supposed to have... Anyways: we're on a budget and are always looking to open source alternatives. We have our students on OpenOffice and lots of touching up is already done with the Gimp. If we can now do other illustrations with an open source tool that is equivalent to Illustrator, well... And we would be happy to contribute to the effort financially as long as it is cheaper than buying Adobe :)

Autopackage!

[arvindn]

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.

Mmm... I'd love it for two of my favorite open source projects to come together.

Re:I'm waiting for milestone 9, EPS, PDF export

[Cthefuture]

You don't need to wait. You can currently "export" (print) to Postscript/EPS. Convert that to PDF, and you're done.

Going the other way is what I'd really like to see. That is, import ps and PDF into Inkscape.

Re:Why SVG?

[dmoore]

EPS is an output file format. It is not meant to be an intermediate file to be edited. For example, SVG keeps track of what objects are "grouped" and their relationship to each other. EPS just contains the lines, curves, characters, etc to be displayed.

The correct solution to your dilemma is to write good import and export filters for EPS into the SVG editor. Naturally, there are times when you would want to edit an EPS file, but such cases should be avoided. You almost always want to go back to the original program which created the EPS and edit in its native format. When this is impossible, you want the ability to convert EPS to SVG. That can currently be done with pstoedit, but unfortunately the SVG plugin is not free software.

color models

[MenTaLguY]

Color models are going to be tricky ... SVG is currently limited to only sRGB by CSS2/3. We're trying to find clean ways to extend SVG/CSS without breaking backwards compatability (and of course we're tracking future W3C proposals along these lines).

Re:color models

[MenTaLguY]

W3C compliant, I think. We are trying to modularize the code more, though, to provide a basis for other (possibly non-SVG-based) tools (implemented by us or someone else). It might eventually mean an internal or external fork, but that's okay. People gotta do what they need.

The other thing is that once we've reached a decent level of SVG-compliance we should be in a pretty good shape to get involved with the development of the SVG spec and help nudge it in appropriate directions.

So we'll see how it works out.