Inkscape 0.91 release
inkscape.org
inkscape.org
The interface and workflows are simple, yet extremely powerful if you spend some time understanding the tool. I have used Inkscape exclusively to do all my interface design work during my career.
After moving to OSX, I was put off by the lack of native support. So I tried moving to Sketch and Illustrator. I found Illustrator to be overly complicated and plain bloated. I've always had a distaste for Adobe software and Illustrator maintains that negative image for me. Sketch on the other hand was unstable when I tried it. It had some serious bugs that made it unusable.
I went back to Inkscape and am now used to the GTK quirks & the lack of Retina support. The software itself remains my favorite tool. And I'm excited to see this major update to Inkscape.
I think a lot of the power of Inkscape comes from harnessing the abstractions of SVG. I've used it in the past as a container for GUI elements, and as long as you name things properly and maintain a good order of abstraction, using Inkscape to create SVG that can be parsed directly into working code is a thing of joy to behold.
However, when it comes to using SVGs on the web, Inkscape is clearly the king. Illustrator has a bunch of nice and fancy filters and such, but you try exporting as an SVG for web and you will find a great deal of your design has been lost due to non-svg-compatabile "frills" Illustrator adds.
https://code.launchpad.net/~suv-lp/inkscape/osxmenu
There are still some bugs, but it works well for me.
<url snipped> - Sorry, the Public links of my Dropbox
account currently are suspended due to bandwidth limits.
[0]: https://www.adhoc-gti.com/hn/Inkscape-0.91+devel+osxmenu-r12...
I uploaded it to Google Drive to save your bandwidth: https://drive.google.com/file/d/0B2dUQpSGutXERFhLSnNmanNBam8...
Please let me know if I am in breach of distribution rules for it.
I simply don't want the link itself to appear elsewhere, I don't care if the whole HN crowd downloads it and send the link privately to their coworkers or whatever.
We're on a 100Mbps link so bandwidth should not be an issue if people are not selfish dicks.
Another reason why Inkscape rocks where other vector editors don't fare as well is in their understanding of Bezier curves. It's right on, just like in Corel Draw. One example of a program that does not get Bezier curves right is Adobe Illustrator. It's impossible, or very very hard, to draw a rectangle, make the top two nodes cusp, and curve only the top side. I remember reading in forums where people were trying to do that and long time users were admitting that it's complicated. However, in truth there's nothing complicated about it, as Inkscape demonstrates very well.
Fine control over nodes is the reason you want Inkscape. Illustrator gets on my nerves because it's so roundabout in this regard.
Example: last week I had to open a bunch of EPS files in Illustrator and extract shapes to make new images. I had to realign shapes all the time, and had to set the "Relative to" field ALL THE DAMN TIME. While in Inksapce it remembers my previous choice.
EDIT: new binaries arent officially posted yet but here's an OSX nightly build from 10 hours ago: https://www.dropbox.com/sh/2n7aim2wcrn6l3h/AAC62qBMxM6317AZi...
Excellent.
Is it the Windows build which isn't prioritized, or is it versioned somewhat differently?
I still recall the first time I tried the included tutorials and realised that the tutorials themselves were just SVG docs. So it had things like, "Let's explore the handles of an ellipse. Select this one", and the shape is right there in the tutorial. Brilliant idea!
http://2dgameartforprogrammers.blogspot.nl/2011/10/lets-get-...
Now I love using InkScape. It was a matter of finding the proper workflow.
Just putting it out here, in case it might also help others.
Typing in the dimensions is the normal way of working with CAD software: http://www.cad-notes.com/autocad-precise-input-specifying-po...
As others have said, you can do something like this in Inkscape, but the interface isn't so smooth.
But for simple things in Inkscape you could enable a 0.5cm snap and stick to that.
1.x tends to fulfil the original goals of the project. As long as there are some unfulfilled goals, it's still 0.x. 2.x, 3.x, etc. are breaking changes, often a rewrite.
http://wiki.inkscape.org/wiki/index.php/InkscapeInvariants are the stated aims of the project and AFAICT they've not achieved the SVG spec compliance completely yet. Though I thought I recalled them aiming at the reduced SVG "basic" set (? if that's what it's called) and reaching it.
I've been a user since it forked from SodiPodi (and indeed was a SodiPodi user too).
The reason why we're still not there right now is because there are some essential things like canvas coordinates, fixed "flow text" support (so it works in browsers), etc that we need to rectify first before we're comfortable with 1.0.
The native OSX beta already works much better than the broken XQuartz thing(in the past you could not even copy paste real vectors, today it requires a special version of XQuartz and changing parameters and other nasty stuff) .
https://www.dropbox.com/sh/b7tyrnugif2ywqj/qpMx1ygywo
Much better than needing XQuartz.
I wonder if there's any chance it could be made to work on Homebrew...?
The speed increase is nice, Inkscape could be painfully slow on complex drawings with lots of paths.
https://www.youtube.com/results?search_query=mac+preview+pdf...
I'm very pleased to see it's under active development.
I'm not convinced C++ is a good choice for user-level applications. Maybe for the performant parts, or for compatibility.
Perhaps other factors like skillsets came into play...
But, yeah, it's going to be easier. It's also an opportunity to consider another language that might improve productivity, reliability etc. in the future. Just wondering. Didn't mean to start a language war :-)
Just wanted to point out that if you have a C code base, it is way easier to port to C++, which isn't a bad language at all.
Maybe others would go for something more modern.
I guess you're right with the skill set, but I'd like to hear it from their devs.
It makes sense to use high level languages to manipulate the document model or to implement widgets, but when it comes to the renderer you want to be as close to the metal as possible.
The migration from C to C++ was slowly progressing since Inkscape was forked from Sodipodi over 10 years ago, but there are still some C files remaining and SP* prefixes are used all over the place.
Besides, Sodipodi was already using simple GObject-based architecture.
I notice there was a discussion about this on inkspace-devel years ago, but it yielded no results from what I can tell.
As long as I work on Windows, there is Xara thankfully. It's got quirks but has been good to me and my workflow. On Mac now thankfully is Affinity Designer. Not quite fully fleshed out but still excellent to have. Inkscape is a great utility program for me that has a lot of low level tweak settings and it's great it constantly gets better.
Best of all, it has great single-key keyboard shortcuts for higher productivity :)
But my heart still yearns for CMYK and (to a lesser extent) spot colour support.
For all the SVG-base CNC apps this would be great news.
This is because everything inside SVG document lives in an imaginary infinite world where dimensions and distances are expressed in abstract "user units".
You use "viewBox" attribute on the outermost <svg> element to specify a rectangular fragment of that world for the purpose of rendering. You use "width" and "height" properties to specify the real-world size of that fragment.
Authoring tools might show you dimensions of SVG objects such as rectangles or paths in real-world units computed from "viewBox", "width" and "height" of the outermost SVG element, but under the hood the size of those objects should be stored in user units.
Not a big deal if you only use Inkscape. The real mess starts when going between different authoring apps. Then pretty soon a 100mm line in Inkscape turns into something longer or shorter. This is when you revert back to DXF, the bastard of all file formats.
I don't see how the viewBox's real world units can solve this. I think the geometries need to actually use real world units (which the SVG standard supports).
Not sure if this is what you meant, but some tiny rounding errors might occur during conversion if there are many transforms involved between the user space and the viewport space, but this can be avoided if user space values are stored with high enough precision.
In order to convert user units to viewport (physical) units and vice versa you only need the current transformation matrix, viewBox rect and viewport size. I have created a demo which shows how I can determine the line length in physical units: http://jsfiddle.net/9n5hf2jw/1/
The way how real world units are interpreted inside the SVG document is so messed up that even the SVG spec itself discourages their use:
Defining the size of a document in mm and then using mm units for shapes within it is going to give counterintuitive results, since they'll be converted to user units to resolve against the view box. (https://svgwg.org/svg2-draft/coords.html#Units)
When I setup up Inkscape to use mm it does set with/height in mm and then the viewBox to the same dimensions (without units). This way it is implying the user/px units (e.g. all unitless dimensions in the file) are basically mm.
Previous versions of Inkscape would always safe in user/px units with an implied conversion of 90dpi, meaning a scaling factor of (25.4/90) to go from values in the file to mm. CorelDraw always uses 96dpi, Illustrator always 72dpi. I am not saying this makes sense. It's just how different authoring apps do it. If you want to use the file in a CNC machine you have to make sense of what the app meant when it uses unitless dimensions. When a file was edited with two different apps it very often is not possible to make a smart guess by some basic heuristics.
BTW: the CNC app I am working on is LasaurApp, part of an open source laser cutter called Lasersaur - http://lasersaur.com
Anyway inkscape is otherwise good- it passes my figure drawing test: draw a ruler with tick marks and numbers. Corel can do it. Vizio can do it. Xfig can do it. Not too many others can (try this with the draw tool built into open office and you'll see).
I did buy both of them a long time ago and used them for many years on an old Mac.
I've also used gimp for approximately 8 years and it has made HUGE strides in the past few years. In fact, I've done a few professional, or semi-professional (ie: not paid) photo restoration jobs recently and I used gimp to do it. Not that surprisingly, people still absolutely loved the work I did restoring pictures of their loved ones or whatnot.
Photoshop still has nothing equivalent to the SIOX background removal tool as the guy who wrote his PHD thesis on it wrote a gimp plugin. If you've not seen it, it is kind of amazing: http://www.siox.org. See this video for an example using a much much older version of gimp: http://www.siox.org/videos/siox-in-gimp.mpg
Think about a new graphics design person coming to photoshop. It is very much a learning curve, a higher one than gimp.
Seriously, that bug has been biting me since 2011. I'm glad to see it fixed.