February 2016 - Inkscape Devel

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

Inkscape for embroidery
by Michael Soegtrop 26 Nov '16

26 Nov '16

Dear Inkscape Developers, I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want. I would like to have your opinion on if you think it makes sense to integrate such functionality into the Inkscape mainline, or if it would be too much of a stretch. It boils down to some LPEs and an export format. The commercial tool I have from Bernina (a Swiss sewing machine manufacturer) is based on Corel Draw. Below is a list of the additions I did / I am working on. Please let me know what you think about this. With these additions, Inkscape offers substantially more flexibility than affordable commercial SW (and affordable here means 500..1000$). Best regards, Michael 1.) Ways to fill an area with clusters of contours Inkscape already offers 2 path interpolation LPEs which allow this. I plan to add a 3rd one which creates a set of equidistant inset/outset paths. 2.) A way to connect sub path of a path into one continuous path I added an LPE to do this with various options of end interpolation. Maybe if I use bool-ops I need to extend it with some sort of sorting, cutting and auto reversing mechanism to keep the connections short. 3.) A way to cut a path into stitches (straight line segments) in a controlled way. I added an LPE to do this, but it is quite primitive as yet. 4.) Bool ops on paths because in embroidery you cannot simply hide an object below another one. I just added a bool-op LPE for this - needs some additional work to cut contours against a closed path. 5.) A tool to convert graphics output to some format an embroidery / sewing machines can read. I wrote an external tool to convert HPGL to a common embroidery format (stitch/DST), but could also integrate this into Inkscape. 6.) Maybe a tool to hide connections between path segments below filled areas. For a sewing machine it is quite complicated to do a "pen up" - it has to cut the threads, so one typically hides connection paths below some embroidery to avoid thread cutting. Currently I do this semi-manually. Doing this automatically might be quite complicated.

11 32

Thanks for your votes! We have our new "Draw Freely" font!
by C R 02 Nov '16

02 Nov '16

And the winner (by quite a bit, actually) is Euphoria Script! Thanks to everyone for the votes and helping us choose a new open font. The new font will be deployed to the website and relevant graphics. You can start using it now in your inkscape-related materials by downloading it here: (includes font and ofl license files). http://www.opendesignstudio.org/inkscape/euphoria_script.zip Have fun, and thanks again for the help! -C

12 26

performance problems and possible remedies?
by Yale Zhang 29 Sep '16

29 Sep '16

Hi. I'm using Inkscape to author a comic and the slow speed for certain things is very annoying. I'm already have OpenMP turned on and using 4 cores. 1. *large blurs are slow* - I'm an expert with writing SIMD code, so I was thinking about vectorizing the Gaussian IIR filter with SIMD intrinsics, even though it's harder than for a FIR. But I noticed there isn't any SIMD code in Inkscape so does that mean it's something to avoid. I'm pretty sure no current compiler is smart enough to vectorize it, and besides, Inkscape is compiled with -O2, meaning -ftree-vectorize isn't on by default. 2. *when there's a large image (raster based) background - scrolling in a zoomed region is very slow* I compiled the latest 0.49 code with GCC profiling and it shows this: 33.98 22.47 22.47 exp2l 21.29 36.55 14.08 log2l 17.57 48.17 11.62 pow 7.12 52.88 4.71 658 0.01 0.01 ink_cairo_surface_srgb_to_linear(_cairo_surface*) 6.72 57.32 4.44 563 0.01 0.01 ink_cairo_surface_linear_to_srgb(_cairo_surface*) 5.51 60.96 3.64 1216 0.00 0.00 Inkscape::Filters::FilterGaussian::~FilterGaussian() 5.23 64.42 3.46 internal_modf 0.59 64.81 0.39 _mcount_private 0.41 65.08 0.27 __fentry__ 0.12 65.16 0.08 GC_mark_from 0.09 65.22 0.06 5579 0.00 0.00 Geom::parse_svg_path(char const*, Geom::SVGPathSink&) 0.06 65.26 0.04 35320 0.00 0.00 bounds_exact_transformed(std::vector<Geom::Path, std::allocator<Geom::Path> > const&, Geom::Affine const&) 0.06 65.30 0.04 8 0.01 0.01 convert_pixbuf_normal_to_argb32(_GdkPixbuf*) 0.05 65.33 0.03 885444 0.00 0.00 std::vector<Geom::Linear, std::allocator<Geom::Linear> >::_M_fill_insert(__gnu_cxx::__normal_iterator<Geom::Linear*, std::vector<Geom::Linear, std::allocator<Geom::Linear> > >, unsigned long long, Geom::Linear const&) The cost is absolutely dominated by ink_cairo_surface_srgb_to_linear() and ink_cairo_surface_linear_to_srgb(). My first instinct was to optimize those 2 functions, but then I thought why are those even being called every time I scroll through the image? Why not convert the images up front to linear and stay that way in memory? If that can't be done, then my optimization approach is: 1. replace ink_cairo_surface_srgb_to_linear() with a simple 3rd degree polynomial approximation (0.902590573087882 - 0.010238759806148x + 0.002825455367280x^2 + 0.000004414767235x^3) and vectorize with SSE intrinsics. The approximation was calculated by minimizing the square error (maxError = 0.313) over the range [10, 255]. For x < 10, it uses simple scaling. 2. replace ink_surface_linear_to_srgb() with a vectorized implementation of pow(). Unlike srgb_to_linear(), a low degree polynomial can't be used due to the curve having larger high order derivatives. An alternative would be piece wise, low order polynomials. The main question I have is what degree of accuracy is desired? Certainly, it doesn't need double precision pow() since the input is only 8 bits! Is +- 0.5 from the true value (before quantization) OK or do people depend on getting pixel perfect results? UJ

7 20

Git
by Krzysztof Kosiński 02 Apr '16

02 Apr '16

Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point. The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think? We can convert lib2geom first and apply the lessons learned to Inkscape. Best regards, Krzysztof

18 59

SpinachCon 2016
by Martin Owens 01 Mar '16

01 Mar '16

Dear users and developers, Inkscape has been invited to take part in the Free Software design day known as SpinachCon which happens the day before LibrePlanet here in Boston: https://libreplanet.org/2016/ The SpinachCon event is about working with users on finding odd, weird and slightly ugly things within inkscape that we can fix or make designs about. If you are in the area and wish to take part it's March 18th 2016, from 12:00-5:00pm, in Boston at Beaucoop's offices (near South Station on the Red Line) I'll report in a new article any findings or fixes after the event. Best Regards, Martin Owens

2 1

Google Summer of Code 2016
by Josh Andler 29 Feb '16

29 Feb '16

Hey all, I just wanted to let everyone know that Inkscape was accepted as a mentoring organization for GSoC this year. This will be our 11th year participating. Google has transitioned from Melange to a new site (1) this year if you're interested in reading more about it. If you are interested in participating as a student please visit our page (2) on Google's new Summer of Code site to find links to our Ideas for summer projects on our wiki and our developer mailing list. As usual, please either introduce yourself on our developer mailing list or let us know what you're interested in working on this year. Student application don't open until the 14th, so now is the time to be talking to us if you are interested in working with us. If anyone has any questions, please ask away. Cheers, Josh (1) https://summerofcode.withgoogle.com/ (2) https://summerofcode.withgoogle.com/organizations/6010720831406080/

1 0

Re: [Inkscape-devel] Inkscape for embroidery
by Michael Soegtrop 29 Feb '16

29 Feb '16

Dear Alexander, > Did you create a branch on Launchpad where I can see your code? I'd > like to test it and possibly contribute to it. Not yet, but I guess within a week. Best regards, Michael

1 0

Screenshots of bool LPE with new slice-inside and slice-outside bool ops.
by Michael Soegtrop 28 Feb '16

28 Feb '16

Dear Inksacpe Team, here are 3 screen shots of the bool-op LPE and the new slice-inside and slice-outside bool ops I implemented this weekend: www.Michael-Soegtrop.de/Inkscape/slice_off.png www.Michael-Soegtrop.de/Inkscape/slice_inside.png www.Michael-Soegtrop.de/Inkscape/slice_outside.png In the slice-outside image please note that the cut shape is transparent - it is not just hiding the lines below. Of cause all normal bool-ops are also supported by the LPE. Since I want to supply a patch for embroidery use based on 0.91 soon, I implemented it based on the old livarot mechanisms, but the new bool ops are just 200 lines with quite a few comments, so I don't see much of an issue to port it later. The main work was anyway thinking about how to do it so that it works reliably and not implementing it. The filltype parameters I will remove and get them from the paths instead. I think these bool-ops are quite useful for normal drawing (not embroidery) as well as a more generic kind of hatching. Best regards, Michael

2 1

Quality of gradients.
by Gez 28 Feb '16

28 Feb '16

A few weeks ago, Tavmjong added a comment to bug #180693, asking if the reported issue was still present with the new renderer. I'm answering here, as I'm adding some personal comments that probably don't belong to the bug report. Please tell me if it's is worth that I add some of this information to the bug report, or feel free to do it if anyone wants to. Regarding the question, As long as Inkscape renders at 8bpc, yes. It will still be a problem. It's possible that some sizes and colors hide the problem more than others, but banding will still be a problem unless images are rendered in higher precision. The easiest way to check this is to draw a grayscale gradient. At 8bpc, you can't paint more than 256 shades of gray. So a 256px-wide gradient will look ok, but as soon as you stretched that gradient to a larger size, banding will appear. An even more extreme example (but not less frequent) is when you also have a grayscale gradient, but instead of going from black to white you go from a middle gray to a lighter gray. If your gradient takes, say 50 levels out of those 256, stretching the gradient will result in severe banding sooner. I don't think it's possible to address banding in 8bpc without some form of dithering, and it looks that the current renderer doesn't apply any. As I mentioned in an older comment, the best way I could find to work around this was using the "spread" filter in GIMP, which jitters the edges of each step of the gradient making it look smoother. There are existing dithering algorithms that could be used too, like floyd-steinberg, bayer, a-diher (http://pippin.gimp.org/a_dither/), etc. but I wonder how effective would they be as we don't have a smooth gradient as a starting point, but a stepped one. Those dithering algos could be useful if inkscape rendered at 16bpc, to bring down the display to 8bpc though. At any rate, rasterizing a vector shape and applying a filter would be prohibitively slow for large sizes so this dithering, if applied, should be probably applied only to export, making this solution unsuitable for on-screen representation. Anyway, I don't think banding is too much of a problem (it is, but it's not as severe) for screen as it is for printing. For printing it becomes a critical issue, as other commenters pointed out. Inkscape is a valuable tool for large format printing which I use daily, and time to time I have to apply some nasty workarounds because of this limitation. For my professional work, the way inkscape renders gradients is a show- stopper. The quality of my work suffers if I don't apply one of those tedious workarounds discussed in this thread. This bug has been reported about 8 years ago, and a lot happened since. Maybe this time, with a new renderer there's something that can be done to get it fixed? Gez

4 11