January 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

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

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

Win64 devlibs update
by Eduard Braun 28 Feb '16

28 Feb '16

Hi all, as some of you might already have noticed I'm working on a major update for the win64 devlibs. Current status: Both trunk and 0.91 build fine and seem to work without obvious flaws on my system! Most of the binaries are contributed by Partha Bagchi whom I'd like to thank very much again! Almost all dependencies were updated to the latest available version and rebuilt from scratch with gcc 5.3. Although work is not yet finished I'm at a point were I'd like to encourage you to test my changes: * If you want to compile Inscape from scratch you can do that as usual [1]. However you'll need a checkout of the updated devlibs branch, see https://code.launchpad.net/~inkscape.dev/inkscape-devlibs64/5.3 The updated compiler is available as part of a MinGW-w64 package available from https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20… Lastly you'll need an updated build-x64.xml. I temporarily uploaded a copy for both trunk and 0.91 branch to my Google drive, see https://drive.google.com/open?id=0B3IZiqBj23X1My1CaUE2NjlpVms * If you want to start testing right away, I also provided pre-built packages available from the same link https://drive.google.com/open?id=0B3IZiqBj23X1My1CaUE2NjlpVms I'll push some further smaller updates in the coming days. If no bugs or regressions are discovered I'll propose to merge the update after that. Thanks for testing, Eduard [1] http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_64-bit

2 4

Re: [Inkscape-devel] inkscape text alignment icons
by Martin Owens 24 Feb '16

24 Feb '16

Dear Claus Staedtler, Thank you for emailing me :-) I think it's a good idea to harmonise where possible. Inkscape's icons are a mix between our icon packs (a tango theme and a symbolic mono-color) none of our themes have text alignment icons (only object alignment icons). In order to use the proposed icons they would have to be installed into the system's icon theme. What is the status of gimp and libreoffice regarding using system icons? Best Regards, Martin OWens P.S. I've forwarded this conversation to the inkscape developer's mailing list (without attachment) we can sort that out later. On Sun, 2016-01-03 at 11:44 +0100, staedtler-przyborski wrote: > Dear Martin Owens, > > first a happy new year > > I recently added to the new gimp symbolic icon theme some icons. > > As my idea is that inkscape/gimp/libre-office .... use the same symbolic > icons whenever they do the same (which is quite often not the case) > I've made additionally made some text-alignment icons for gimp (it uses > currently system-icon-theme, like inkscape). > > I thought inkscape might want to use these icons too (so they would be > identical in gimp and inkscape and libreoffice). > > I've added symbolic and colored icons as svg. The symbolic icons are > derived from libreoffice, you might want to correct the color (for what > reason ever, inkscape uses different gray than libreoffice and > libreoffice a different than gimp in their symbolic icon theme ..., > maybe someday in future this will be harmonized too). > > It's up to you to make use of them or put them into trash. > > Regards > > Klaus Staedtler >

2 1

Rotation tool
by Jabiertxo Arraiza Cenoz 24 Feb '16

24 Feb '16

Hi any one could tell me if a SVG tag could contain a transform inside? I try it on 0.91+devel, the elements are transformed but the controls of items and the rubberband is not transformed. To get more on the idea to know if could be done, the tool is a rotation tool that rotate the draw from the cursor betweeen 360 degrees. There is also a angle constrain modiffier and a reset button. Basicaly need to know if is svg compilant the transform on svg tag. And if yes, how rotation and other trannsforms -only for info- affect to the viewbox? Cheers, Jabier. https://blueprints.launchpad.net/inkscape/+spec/rotating-whole-document https://bugs.launchpad.net/inkscape/+bug/170498

3 3

C++11 configure fix
by Krzysztof Kosiński 16 Feb '16

16 Feb '16

If anyone has a distribution that requires C++11 to compile against gtkmm, please test this fix: https://code.launchpad.net/~tweenk/inkscape/cpp11-configure-fix Best regards, Krzysztof

2 15

Create releases more regularly
by Sebastian Zartner 15 Feb '16

15 Feb '16

Hi there, I initially asked at inkscapeforum.com<http://www.inkscapeforum.com/viewtopic.php?f=22&t=15755&p=63224>and was told to better post my request to this mailing list. I wonder if it wouldn't be possible to create releases more regularly. Currently there are many months or even years between each release of Inkscape. Bug fixes should get out more quickly and it should be possible to try out new features of upcoming versions. Most users don't have the possibility to build Inkscape by their own, so they have to wait for the next release. Unfortunately the provided development downloads are not synchronized, hosted on different third-party web sites and out of date (currently especially the Windows version). So I suggest to create a (more or less) fixed fast release cycle for normal releases (e.g. every two or three months) and periodically (e.g. every one or two weeks) create alpha versions. Alpha versions should be built (maybe even automatically) for all supported OSes and hosted directly on inkscape.org. Sebastian

17 40

Impressions on Inkscape after extended usage
by Michael Grosberg 05 Feb '16

05 Feb '16

Hello, In the past several months - closer to a year, actually - I've used Inkscape in a tight production environment almost daily. I have produced hundreds of illustrations for a computer-based technical course. During that period I used Inkscape 0.48.5 and lately switched to test builds and release candidates of 0.91. All of this time I have kept a list of the problems I ran into using Inkscape. Some are plain bugs, some are more complex problems for which I have no idea for a solution. After testing the new version to see whether some of these problems have gone away, I thought I might share this document with you. Before I go on, I just like to say that these are mostly minor points. I am an avid user and promoter of Inkscape even though my workplace has provided me with a legal copy of Adobe Illustrator, which I think is inferior in ease of use. I think Inkscape on the whole is a brilliant piece of software and I'm thankful for all your efforts. But some problem just kept popping up again and again. So without further ado, here's the document (it's a google doc): http://bit.ly/1yLzn0y Thank you for any comment or feedback you might have. - Michael Grosberg

4 5