Slashdot Mirror
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.
Another interesting Vector Graphics program is Flash 4 Linux; http://f4l.sourceforge.net/ Although in Alpha, it is quite usefull. Its a flashlike program (very similar interface to flash studio), and it is quite far along. It does animations and everything (I believe it doesn't have full flash script abilities yet). It can create flash files.
Help Fight SPAM today!
It's a great discussion on how, when you've got the right players and attitude, Open Source can really work.
tasks(723) drafts(105) languages(484) examples(29106)
So...which is worse? Not reading the article and commenting, or reading the article and only reading what you are looking for?
Right before your quote, "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.".
Did ya miss that on your way to bash these folks?
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Perhapse you missed in the paragraph above the one you quoted:
according to the roadmap, pdf and eps export will arrive at milestone 9 (inkscape 0.43). The project has currently completed milestone 4 (inkscape 0.39, though .38 is what sourceforge has for download).
It'll start to get real interesting for me when I can make .eps and .pdf objects
--- Often in error; never in doubt!
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 it's 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.
Inkscape, Page 2/2
One of the first areas of focus was to add menu items and keyboard shortcuts for the commands it provides. Mentalguy had just recentl
If you like inkscape, but you find there is a feature you need is missing, request it here.
The Inkscape developers have implemtneted loads of cool features already, and you can help it make it even beter.
You can even contribute patches if your feeling bold.
Also, here is the Roadmap on their wiki.
It isn't serializing the data, it is actually creating a Scalable Vector Graphics file which is an XML based language that you could then use on a web page or in any app that can read it. Think png vs psd.
(Yes I know that PSD is a published format...)
The EPS format is just a set of comments around a PostScript program. Now, postscript is a complete programming language. People have implemented things like ray tracers and web servers in postscript, and there is nothing to prevent you from putting things as complex as that in your EPS files
Even if your program had a complete postscript interpreter, how would it translate an arbitrary program to something that makes sense in a gui?
Note: there are known issues with certain (rare) setups which have a non standard umask and X security settings. If you are on a stock Red Hat/Fedora install all should go smoothly (let us know if it does not). If you have tweaked your umask or have X security too restrictive (programs run as root must be able to connect) things will break.
If you want to test inkscape quickly and you are on x86 Linux, this is an easy way to do it. Just be careful. autopackage is in beta. If it breaks you get to keep the pieces.
The feature is that it stores its drawings in SVG, not any random XML format. That's a bit harder, and far more useful, than just using an XML format instead of a binary one.
Come on, you only needed to read just a sentence or two more of the article to get the explanation.
Judging a format on the base of its file size is stupid, to put it mildly. You can always save your files as SVGZ (gzipped SVG) and get nice small binary files. Inkscape supports reading and writing SVGZ transparently.
> "...one of Inkscape's distinguishing features is that it stores its drawings in a web-friendly XML format"
You did not read the sentence fully.
It is:
"...one of Inkscape's distinguishing features is that it stores its drawings in a web-friendly XML format -- SVG"
And that is huge. Inkscape is an SVG editor.
Illustrator from version 10 on can save in SVG format and Inkscape reads them in perfectly!
-- Now more the mirth, scrape here in the face...
Well, I think the main motivations were to change the code to C++, to rely on third-party libraries if these were actively maintained and (I think) were available on different platforms, to get an interface more HIG-compliant and to make emphasis on a small core with extension capabilities.
But you could read it better in this pages of Inkscape's wiki.
No, vector graphics are a different enough beast, that you need a completely different set of tools for dealing with them. What you really want is for gimp to be able to import external SVG things and convert them to an arbitrarily scaled bitmap representation in a layer. From what I've seen, gimp 2.0 can already do that.
Though, It would be nice if gimp could regenerate the layer automatically when the source SVG file changes. I don't think it can do that yet.
Need a Python, C++, Unix, Linux develop
Last time I tried Inkscape I was surprised that no support for Layers could be found. IMHO Layers is an essential feature in any decent modern graphic editor. And what is the deal with the "Spiral" tool as a main drawing tool? Does anybody ever have a need for a spiral drawing tool? In my eyes it seem like the featureset is more determined by the inherent capabilites of the SVG format rather than the needs of the users.
But OK, OK... it may be because my need is for technical drawing tool more than an artistic drawing tool. You may also read the opinions in the The Grumpy Editor's diagram editor followup
Sodipodi is pretty good, IIRC.
Inkscape is a fork of Sodipodi, with a more open approach and an emphasis on using C++. The result is a program that builds upon Sodipodi's good points by adding a better user interface, handsome new features (like boolean operations), as well as being a lot more stable.
My impression is that Lauris Kaplinski (the Sodipodi maintainer) was doing a David Dawes impression and holding Sodipodi development back in one way or another, and Inkscape is the result of all the frustration that built up. Now the momentum is with Inkscape which has a bright future with a lot of active developers.
Also, the "unorganised approach to open source" comment in the story is very unfair. Inkscape is a very well organised project and Bryce in particular is very diligent about keeping the future well mapped out. The "unorganised" jibe is really because Bryce and Co let people hack on features they want to hack on, and readily accept them if they meet a decent standard. But isn't that what open source is all about? And isn't the reason for many forks and/or project stagnation due to this being prevented? I'd say "open minded" is a more appropriate term.
Free Gamer - Free games list and commentary
You and I must be living in different universes, then. Propeprietary vendors are at least as bad feature whores as Open Sourcerors... those bells'n whistles are THE very first thing sales people get added, well before things that would make things more stable or easier to use.
And yes, I'm software engineer and have worked for a few shrink-wrap software vendors, including Adobe's biggest competitor.
This is not to say developers shouldn't try to think carefully about what to add, how and when, just to point out commercial companies are not much better. It's just that THEIR process is a black box, and outsiders generally do not see how screwed up it is, whereas process (or lack thereof), goals, philosophies and practices of Open Source projects are usually transparent and can be freely debated.
Bryce Harrington, Inkscape's founder, wrote an article introducing his brainchild and where its development is heading
Quick correction - I was one of several people that founded the Inkscape project, but I definitely can't claim credit for the application itself. As mentioned in the article, it derives from Gill and Sodipodi, so if it is anyone's "brainchild" it would be the developers of those projects. That said, Inkscape as it is today is the amalgam of a number of people's ideas and hard work, so it is most definitely a team effort. :-)
Basically, the plan is groups = layers. I implemented a first cut at that a long time ago (set inkscape:groupmode="layer" on a group [hopefully I'm remembering the attribtue name here..]), but nobody's gotten around to doing UI for it yet.
I expect it'll get done fairly soon since even I'm beginning to feel the pain of not having it implemented all the way yet. ^_-
DNA just wants to be free...
Perhapse you missed in the paragraph above the one you quoted:
And also note that before this there had been another patch that implemented booleans that we had to reject on licensing problems with a General Polygon Clipping library it used. We'd contacted the GPC author to see if he would let us use it under the GPL, but his license was firm (it allowed for educational, non-commercial use only IIRC), so we ended up not being able to use it.
"Check licensing, then patch, and ask other questions later" doesn't quite have the same ring though. ;-)
Agreed.
I'm one of the founding developers. We might joke about being an Illustrator killer occasionally, but really that's not what we're about. That wouldn't be a healthy focus, and the _best_ we could hope for in that case would be becoming a (marginally) better Illustrator clone.
That wouldn't be so great, IMO. Illustrator does a lot of things, but it doesn't always do them well, and the UI is painful at times.
Realistically, we are going to do some things well which Illustrator does poorly, and we will do some things poorly which Illustrator does well.
We just wanna make a good and useful tool and be the best we can be dammit. All this "foo-killer" stuff is silliness. ^^;
DNA just wants to be free...
EPS is PostScript. There are maybe a half dozen things that you can't do in EPS or must do that you otherwise have freedom to ignore in PS.
The problem with EPS as a file format is that it is too powerful. It is a language far more than it is a standard file format. To make a EPS importer you need a major chunk of code to parse all the possible EPS files that one could generate. You need a PostScript parser - a complete one. You just don't need the PS renderer. You need all the memory management and font handling.
I am not an SVG expert (I'm not sure I qualify as a PS expert either, but I work with it for a living), but I think it is much simpler in theory to implement one than a PS interpreter. Especially since the base language is XML and the parser for that already exists. I also believe that animations (automation?) in SVG is based on Javascript (and/or others?) so that already exists too.
Last, SVG has a nice structure. (E)PS is pretty damn free-form. Writiing tools to work with SVG without actually having to parse all of it is much easier than doing the same with EPS.
Lump lingered last in line for brains, and the ones she got were sorta rotten and insane.
As I see it, SVG is "The Future." As for "real world", I believe SVG will be in the "real world" pretty quickly, and it's already gaining a lot of foothold, which can only be a good thing.
It works fine as an editable format that can be worked on in many different applications without losing any data in between (EPS is just an intermediate format that loses editing-related information) - there's common stuff that specifies the image data and additional, program-specific stuff can be added with additional XML namespaces (sodipodi and inkscape both do this).
Also, you can put any kind of XML metadata inside SVG, for example, Dublin Core elements, Creative Commons tags, you name it. You can do that much hot "semantic web" stuff in it, I suppose.
SVG also interfaces nicely with web browsers, right through the DOM. (At least in theory. Let's wait until Mozilla finally gets SVG out of the alpha, and Microsoft to catch up within a decade or two =) Think Flash, but without a stone wall between the plugin and the browser.
Also, SVG supports graphically stuff that's pretty hard to find in PS world. I still have slight problems getting alpha blending to work beautifully in EPS files (at least in OSS apps!), but I've not had any problems with that in SVG.
SVG is technically easy to work with. It's just XML with some plain-text sublanguages (like path declarations). It is not a Turing-complete language like PS, but it's rather purely just data, so it's probably far easier to work with. Yeah, in this respect, it's perhaps not as "powerful" as PS, but I've mostly seen PS's "power" being used only in gimmicky situations. Algorithms may get you to the stars, but Data gets you pretty damn far in real world.