August 2016 - Inkscape Devel - Inkscape Mailman

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

xverbs
by Dmitry Zhulanov 26 Sep '16

26 Sep '16

Hi, all! Im a game developer and using the inkscape for layouting my game screens. Loading_screen_layout.svg one of them. It have g with id pause_button and rect with id sandclock_bound which I use for animation placement. The verbs feature which inkscape already have is have some limitations. The MAX_PATH for example. Also some verbs required user interactions, so I need some eXtended verbs here. Using python script I have load layout as xml and collecting element-id's of interactive elements with "onclick" attribute, for example. Using this element-id list I generate .yaml, which is some sort of batch file. Here is the .yaml file which is used with Inkscape to clean up layout and put button image in separated file with pause_button.svg filename. Also I count undoable actions to restore state generating verb EditUndo. command: inkscape -B loading_screen_layout.yaml ----------- loading_screen_layout.yaml --------- run: - xverb-id: XFileOpen, loading_screen_layout.svg - xverb-id: XUndoLabel, fresh_document - xverb-id: XSelectElement, pause_button - verb-id: EditInvert - verb-id: EditDelete - verb-id: FitCanvasToDrawing - xverb-id: XFileSaveAs, pause_button.svg # save with stupid name - xverb-id: UndoToLabel, fresh_document - xverb-id: XSelectElement, pause_button - verb-id: EditDelete - xverb-id: XUndoLabel, fresh_document - xverb-id: XSelectElement, sandclock_bounds - verb-id: EditDelete - xverb-id: XUndoLabel, fresh_document - xverb-id: XFileSaveAs, loading_screen_layout_release.svg # save with stupid name - verb-id: FileQuit ------------------ CUT HERE -------------------- I guess you can get readonly access on my launchpad page. https://code.launchpad.net/~dmitry-zhulanov/+junk/inkscape-xverbs Code is tested with mingw+windows7+VS2010 sdk. If you would like to merge the feature, I will clean up code to conforming code style, remove printf's & so on Any help or advice are appreciated! P.S. sorry for my bad english :) Best Regards, Dmitry Zhulanov

6 17

CMake now working on Windows
by Sebastian Faubel 05 Sep '16

05 Sep '16

Hello everybody, I submitted a merge request of my Inkscape branch yesterday. Thanks to Marc it has already found its way into trunk - big thank you for the quick review. The branch I submitted now has full support for compiling Inkscape on Windows with 32-Bit and 64-Bit environments. It also supports out of source builds and should also work with Unix llike command lines such as Cygwin and MSYS. After weeks of investigation I managed to get locales to work and have an executable icon along with all application icons. Actually, the only thing that it distinguishes from a btool build now is that it does not (yet) produce the inkscape.com console binary. However, that should not be a big deal. In all other regards it should be ready for testing and packaging. I already updated the Wiki page with the new compilation instructions. Again, thank you Marc and hopefully we're a step closer now to a 0.92 release on all platforms. ~Sebastian *Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg, Germany | Phone: +49 821 8854401 | Fax: +49 821 8854410 | www.semiodesk.com This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Semiodesk GmbH is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

8 14

Stroke to path
by Jabiertxo Arraiza Cenoz 02 Sep '16

02 Sep '16

Hi to all. This is a requets tor change "path->stroke to path" menu item to another definition -string- based in a new code. My proposal is path->to path This new code basicaly do a convert stroked item to path retaining paint-order, fills and markers. The patch is here: https://bugs.launchpad.net/inkscape/+bug/1556592 Cheers, Jabier.

2 5

Inkscape Board Meeting Sep 2nd
by Bryce Harrington 29 Aug '16

29 Aug '16

Hi Inkscapers, For September's board meeting, I'd like to plan on getting together this Friday, September 2nd, at the usual time, noon Pacific, in #inkscape-devel. http://wiki.inkscape.org/wiki/index.php/Board_Meetings Last meeting we discussed hackfest locations. My wife's been helping me scope out some awesome places in the area, and we have a good option to present. We'd also talked about sending a few folks to a GNOME event this fall; this meeting will be the last opportunity to get that underway if we want to do it. Another important agenda item is to follow up on the Inkscape Forum transition, and discuss follow up tasks. I've also started working on setting up an Inkscape account on Spreadshirt and put some Q's in to SFC regarding bank info and taxes, but am hoping that will be ready for usage soonish. So I'd like to chat with Mc and anyone else that would like to participate in getting that off the ground. Bryce

1 0

The Website is Down
by Shlomi Fish 29 Aug '16

29 Aug '16

Hi all, as reported on Freenode, https://inkscape.org/en/ gives a "502 Bad Gateway" error. Please look into fixing it. Regards, Shlomi -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ “Talk Like a Pirate Day” is the only day of the year when Chuck Norris only talks like a pirate, and does not actually act like one. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post

4 3

Doc scaling compatibility issue (Bug 1389723)
by Bryce Harrington 26 Aug '16

26 Aug '16

What do you think we should do about the release-critical DPI bug? We need a decision on a course of action. One of the changes we're bringing in this release is changing the definition of px from 90 dpi to 96 dpi, but a consequence of this is that documents created in 0.91 or earlier will become mis-scaled if used in 0.92. This is tracked in the following bug report: https://bugs.launchpad.net/inkscape/+bug/1389723 This is a release-critical bug, the sort that is likely to become a thorn in our side in the near to mid term as users start running into it more and more. Longer term it will diminish as our users move to newer versions, but I imagine it'll take multiple years before it goes away completely. I don't think we should consider reverting the change; it was introduced pretty early on this development cycle so backing it out could cause secondary bugs to crop up. Also, it's a change that has to be done, so if we don't do it this release we'll have to go through all the trouble again next release anyway. One proposed approach is to detect the affected files on load and display a warning with a recommendation to convert the file manually. Javier has posted a conversion tool that could be made use of; it's received a fair bit of testing but there may be some remaining corner cases to sort out; on the plus side with it being a discrete utility fixes could be rolled out for it without needing full Inkscape releases. The other proposed approach would be for Inkscape to internally convert files, so that no warning is needed. In theory this would provide a better user experience, but is going to require a lot more developer effort and thorough testing. I'm doubtful that all of this can be done adequately within the timeframe we're looking at for the release. Both approaches also require a mechanism to detect affected files, which sounds like it may be the tricky part here, as our SVG documents haven't had versioning information we could rely on for this case. Do you have thoughts on other ways to address this issue? Do you have a strong opinion on whether for this release we should use the expedient approach or else postpone the release until the more user-friendly approach can be developed? Or should we reconsider a revert of the DPI switch so we can get the release out and re-enable it post-release in hopes the issues can be worked out? Bryce

8 18