October 2015 - 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

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

Re: [Inkscape-devel] Devlibs 46 too slow
by Mark Titchener 04 Feb '16

04 Feb '16

I tried your modified build with an NVidia Quadro 1000M on Windows 7 and it seemed okay to me. > Le Jeudi 21 novembre 2013 9h09, Nicolas Dufour <nicoduf@...48...> a ?crit > : > > I'm still investigating the issue, and just found out that the computers > I > > used to reproduced the bug were all using an Intel GPU. Tests with an > nvidia > > GeForce 210 (GT218) show no slowness at all. > > Could some Windows users help me? I'd like to confirm the slowness only > affects Intel graphics cards. Could you test a modified Inkscape binary > (from ftp://download.tuxfamily.org/inkscape/inkscape-12282-cairo-1.12.8.7z), > give your graphic card model and tell me if it's slow or not? IMHO it could > be a blocker for 0.49 on Windows. > >

3 3

Jenkins administration
by Johan Engelen 23 Dec '15

23 Dec '15

Hi all, Jenkins, our CI system, has been down for more than a month. It looks like the disk has filled up, and we need to do clean up / the build tasks should clean up after themselves better (I suspect it has to do with storing the results of too many older builds instead of just the current one plus a few recent builds). We need an administrator for Jenkins. Currently, I think only me and Bryce have access, which is not good enough. Who is interested in maintaining the automatic build/testing system? Of course, you can tailor the system to your own likes; there is much to be improved and I think all are open to whatever crazy plans you may have :-) http://jenkins.inkscape.org/ regards, Johan

5 10

Developing on Mac
by Michael New 15 Dec '15

15 Dec '15

Hey Inkscape developers, I’ve spent the last several years both using Inkscape and working with C++, and I’d really like to contribute to the project now that I have some relevant skills. I develop on macs though, and I can’t seem to find any up-to-date instructions on building for mac. Can anyone point me to some current info? Thanks for the help, and thanks for everything you guys do. -Mike

8 21

Vertical text & 'text-orientation'
by Tavmjong Bah 18 Nov '15

18 Nov '15

Hi, I've implemented the CSS 3 'text-orientation' property which controls how glyphs are rendered in vertical text. This property replaces the 'glyph-orientation-vertical' property which Inkscape never implemented and is deprecated in SVG 2. While doing this work I also corrected some other layout issues with vertical text and with multi-line text. As this work is rather invasive I've pushed my changes to a new branch which can be checked out via: bzr branch lp:~inkscape.dev/inkscape/writing_modes Please test this branch! Here is a list of the most important changes: * Latin characters in vertical text will be drawn by default sideways. This is the default direction in both SVG 1.1 and in CSS 3 Writing Modes. Currently Inkscape draws the glyphs upright. * Punctuation characters in CJK vertical text will be orientated correctly. * The Text Toolbar can be used to set 'text-orientation' which controls how characters are orientated in vertical text (it has no effect on horizontal text). The three choices are 'mixed' where the glyphs are drawn in their Unicode defined natural orientation, 'upright' where all glyphs are drawn upright, and 'sideways' where all glyphs are drawn sideways. * The new CSS 3 values for 'writing-mode' will be recognized. The values written out are still the SVG 1.1 values except for the new 'vertical-lr' value which has no equivalent SVG 1.1 value (and is required for Mongolian). A new button appears on the Text Toolbar to select this value. (The SVG 1.1 values are deprecated but must still be recognized by SVG renderers.) * Fonts without vertical metrics will have a vertical advance of 1em. The CSS specification explicitly does not define what advance to use but the SVG 1.1 spec suggests 1em and the W3C Japanese text document specified an advance of 1em. * In laying out multi-line text, any 'leading' value from the font is ignored. CSS dictates that the font-size corresponds to the em height of a font which is defined as 'ascent' + 'descent'. The change to ignore the "internal" font 'leading' may make small visual changes in how multi-line text appears. * In flowed text, Inkscape has been using a "scaled" value of 'ascent' to position the first line. This has been changed to follow the correct CSS prescription of using the value of 'half-leading' + normal 'ascent' for horizontal text (to find the alphabetic baseline) and 'half -leading' + half em width for vertical text (to find the center baseline). (The 'leading' in this case is the extra space needed between lines as dictated by the 'line-height' property. It is not the 'internal' font 'leading'.) Tav

3 6

Any Inkscape gurus here got any game / animation experience?
by Philip Rhoades 09 Nov '15

09 Nov '15

People, I am going to develop an Open Source interactive game for designing the neural architecture of a VERY simple alien organism - for research purposes. I am thinking that Inkscape is a sort of (more complicated) version of the interface that that would be required. During the game, after a bit of design, the alien organism should animate to some extent (depending how good the design is) because of the nerves interacting with the muscles and other cell organelles - which all correspond to SVG objects - is this a sensible method of proceeding? Thanks, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil@...1587...

5 6