- Inkscape Devel - Inkscape Mailman

Automating an Inkscape workflow
by Eric Greveson 04 Jul '13

04 Jul '13

Hi all, This is my first post to the Inkscape developer list, so - hello! I've been using Inkscape for various server-side operations as part of a project I'm currently working on, and I believe I've run into the limits of the existing scripting / extensions capability. However, I'll describe my requirements, problem, current solution, and proposed improvements, and see what you think. The requirements: I wish to perform "deep subtraction" of one pre-defined path (let's call it P) from an SVG - that is, to perform a Boolean difference operation against each path within the SVG (let's call them S1, S2, ... Sn) such that a 'hole' (in the shape of my path) is punched through all of the SVG layers. The problem: Inkscape Boolean difference operations operate on pairs of paths, such that the uppermost of the two paths is subtracted from the lower path. The operation may only be performed on selections of two paths (i.e. you can't select 10 paths and have the uppermost path be subtracted from all of the lower 9 simultaneously). My current solution: The obvious approach is to simply perform the Boolean operation once for each path in the SVG, cloning the path P to allow it to be subtracted again each time. That is: Create P Perform S1 - P Create P Perform S2 - P ... Create P Perform Sn - P This results in every path in the SVG having P subtracted, which is exactly what I want. To implement the "Create P" operation, I've written a Python extension that inserts a <path> element into the document (i.e. I can create P by simply executing this extension script within Inkscape). To perform a difference operation, I can use the (somewhat maligned?) command line interface with --select <id of S1> --select <id of P> --verb SelectionDiff and I can automatically call my "create P" extension with --verb <my.extension.name.noprefs>. I therefore just have to ensure all paths in the source SVG have IDs, extract these IDs, and then chain a big long command line together to perform all the creation, selection, and Boolean subtractions. I accomplish the ID extraction with my own Python script (running independently from Inkscape, simply using normal XML parsing code) and get that script to concoct a long string of command-line arguments. The obvious problem here is that for files with more than a few IDs, I run into the command-line argument length limit. I have hacked around this by editing Inkscape's main.cpp file and allowing it to take --select / --verb arguments from a text file instead (note that --shell does not do the same thing - it still requires all commands to be on one shell-line, and the line length has a limit). Clearly this is not particularly clever, although it does work - it means I have my own special build of Inkscape and it uses an extremely clunky "scripting" mechanism. The proposed improvements: I have looked at alternative solutions and have come up with the following: - I could edit the C++ code for Boolean operations such that the difference operation works on more than one path. However this is very specific to my problem, and it's likely that I'll want to perform other Inkscape automation tasks in future that don't use the Boolean ops. - There appeared to be some DBus API at one point but it seems to have fizzled out ( http://comments.gmane.org/gmane.comp.graphics.inkscape.devel/40384 was a useful discussion) - and DBus isn't really ideal for this kind of scripting anyway. - Allow further scripting of Inkscape through a Python API - this is my preferred solution, and also, it seems, several other peoples'. The major drawback is that this is likely to be more coding work. However, I have a suggestion that will solve my immediate problem and potentially be useful to others. If I wrote a Python API that allowed Inkscape extension scripts to execute Inkscape verbs and selections, then I could perform all of the necessary operations inside a single Python extension. I could then run the extension from the command line in the usual way (--verb my.extension.name.noprefs). Initially this might take the form of an extra couple of functions on the Python inkex.Effect object: - do_verb(verb_name) - select_ids(id_list) Then any Inkscape Effect extensions can execute verbs and modify selections as they see fit. Does this sound like a good plan? Any other input? I'm happy to write the code for this if you think it would be generally useful, it seems a bit limiting at the moment that effects essentially have to modify the raw XML document themselves to get any useful work done. If the "do_verb" function was modified to take an argument list (along with the appropriate C++ functions), then it would allow for even richer GUI-free interaction (e.g. automation of "Save As" operations and so on). Thanks for reading such a long message, Eric

3 13

[Tracing] Weekly status report #3
by Vinícius dos Santos Oliveira 02 Jul '13

02 Jul '13

Well, I'm late (at least in my mind) and I'm sorry about that. In this week's update, libdepixelize is able to generate the generalized voronoi diagrams. As every week's update, I'm attaching some samples for fast tracking of the project. The next steps are: - Extract the spline curves from the graph (it should be this week, but I'll have to delay) - Optimize the curve I'll do a presentation about my "hobby project" on FISL and I'll need this week to prepare the surprise examples, the slides and so on. Then, I'm taking a week off, but I'll try to not delay anything. See ya! -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

4 7

[Units] Length Class and Refactoring
by Matthew Petroff 02 Jul '13

02 Jul '13

Since my last update, I have implemented a "Length" class to store a length with its unit and perform unit conversions and have begun porting code to the new class. http://www.mpetroff.net/archives/2013/06/29/length-class-and-refactoring/ -Matthew

4 4

GSoC 2013: Implement a new raster-to-vector algorithm...
by Vinícius dos Santos Oliveira 02 Jul '13

02 Jul '13

I'll be coding for this project very soon and I created a repository for it at https://github.com/vinipsmaker/kopf2011 . When we decide where is the best place to keep the project during the WIP phase, I'll move it. I'll be using the namespace *Kopf2011* for this library. If you don't like the namespace, let me know and I can change that. I'll publish updates of the project at my personal blog at http://vinipsmaker.wordpress.com/category/computacao/gsoc2013-inkscape/ . Let me know if you need anything else. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

10 27

Review Request: Selection Transform Refactor
by Martin Owens 02 Jul '13

02 Jul '13

Hey Inkscape Devs, I need some reviews of my new branch available here: lp:~doctormo/inkscape/seltrans-refactor It's a refactoring of the selection transformation code. Not a complete rewrite, but a considerable change. The aims of these changes are: * To merge center exceptions, making them more natural * Reduce line count by 80 lines, 244 lines removed 164 lines added * Reduce class to non-class to class calling * Identifiable handle type, remove assumptive code that uses other properties to guess what kind of handle it is. I have a feature I'm planning to add in and this refactoring will help with that. If you can review this code, I'd be most grateful to know if I've done anything wrong or if you can see other ways to improve the factoring. Best Regards, Martin OWens

1 0

LPE: Scaling Skeletons
by Martin Owens 01 Jul '13

01 Jul '13

While investigating bug 616198, I'm showing a weird crash at live_effects/lpe-bendpath.cpp:108 the uskeleton.cuts variable is either not set or not setup correctly and borks. I couldn't work out exactly what to do since it's not anything I can see. I'd love to know what's going wrong with this bug to improve my understanding of C++. Any help would be greatly appreciated. Martin, https://bugs.launchpad.net/inkscape/+bug/616198

3 3

Object-oriented extension development with play-SVG
by Cosmo Guffa 01 Jul '13

01 Jul '13

Hello developers, I'm writing to announce the recent re-release of play-svg, a set of python libraries aimed at generative and geometry-based coding for creating SVG files: https://github.com/cosmo-guffa/play-svg, with some minimal documention here: http://cosmo-guffa.github.io/play-svg/ . It includes some Inkscape extensions for plotting various geometric objects as well as many more scripts demonstrating its use. Currently the extensions are undocumented, though most of them are pretty self-explanatory in live preview mode. My project went defunct in 2009 when the pyxml libraries got canned. I recently decided to dust the project off and get it back up and running. I noticed the Inkscape community implemented the use of lxml and so I decided to do so as well. I'm realizing that having to install the libraries before using the extensions is an impediment to their use. However, I think that they could serve as a valuable resource for extension developers who want to strip out a lot of the lower-level coding that goes on. Particularly, I've implemented object-oriented creation of paths with some useful helper functions and created an object-oriented interface to creating all svg elements. What I'm wondering is, would it benefit the project to include play-svg and its extensions in Inkscape ? If so, how could they best integrate ? I would like to preserve the ability to import the libraries in stand-alone scripts for those who have already installed Inkscape. What could I do for the project to make it as high-calibre as the Inkscape software itself ? Your feedback would be greatly appreciated :) Sincerely, ~Cosmo

2 1

Tentative patch for downscaling in Cairo
by Krzysztof Kosiński 30 Jun '13

30 Jun '13

Hello I had a look at how complex would it be to add correct downscaling to Cairo now that Pixman supports convolution filters. It turns out it this is rather easy. Here is an initial, minimal attempt. It uses convolution filters only if the image is being downscaled by more than half a pixel in at least one dimension. Some discussion: 1. The sampling and reconstruction kernels are picked in a way that gives comparable quality when upscaling and downscaling. I paired box sampling with bilinear reconstruction and impulse (point) sampling with box reconstruction. This gives the expected result for NEAREST filter. BEST filter uses Lanczos3 for both kernels. 2. Subsampling bits are always set to 1, since this doesn't seem to affect quality at all. 3. I am not sure whether this code works correctly for matrices with a skew component. It should be OK for any combination of scale, rotation and translation. 4. This patch causes new failures in the test suite: - recording-surface*: possibly an effect of improved quality. - surface-pattern-scale-down*, surface-pattern-big-scale-down: the reference images should be updated. - pthread-same-source: I have no idea why this is failing, since this test shouldn't even trigger the new code. - large-source-roi: this test attempts to downscale an image which is 30000 pixels wide down to 7 pixels. The filter parameters seem to be created correctly, but they might trigger an overflow somewhere in the convolution code; the output rectangle is white instead of red, as if nothing was drawn. - device-offset-scale: there are subtle differences which look like convolution-related smoothing; I'm not sure whether this is OK or not. Note that master currently fails many more tests, I only listed new failures cause by this patch. Regards, Krzysztof Kosiński

4 10

Workflow with bazaar and the append-only trunk (used to git)
by Christoffer Holmstedt 30 Jun '13

30 Jun '13

So hopefully I will have access to trunk in a couple of days and before committing directly to trunk I want to confirm that I've understood the workflow with bazaar correctly so I don't mess anything up and make it as easy as possible for me to develop. I use Ubuntu and work from the terminal. I've read the http://wiki.inkscape.org/wiki/index.php/Working_with_Bazaarpage a couple of times trying to figure out exactly what workflow would suit me. The SVN style goes away directly (I want to do everything locally first and push only when I say so). The git-style branches with bazaar seems somehow forced into bazaar and not very appealing to me. I'm left with the branching and pushing...and I can live with the little longer time it takes to branch the big codebase. My questions: 1) The big "gotcha" is that I shouldn't merge trunk into my feature branch and then push back to trunk, is this correct? 2) If I develop a new feature in a separate branch is the following workflow a correct way to get it into trunk? cd trunk bzr pull (get the most reason trunk first) bzr merge ../myproject bzr commit -m "Added myproject" bzr push Regards -- Christoffer Holmstedt

4 14

[Recolor] Weekly Progress #1
by Arshdeep Singh 30 Jun '13

30 Jun '13

Hello devs, I spent the first week researching requisite stuff (more or less) so I am not counting that as the first week. [Making 24th June as the start point]. As planned in the Timeline, I have successfully rewritten the colorwheel code and modified it to a new GUI very similar to that of Adobe Kuler's Editing GUI. Here's a snapshot. What it looked like earlier: [image: Inline image 2] What it looks like now: [image: Inline image 3] Notice the following changes: 1. ) The saturation is now handled by the distance of the node (the hollow circle on the wheel) from the centre. As we move closer to the centre, we get less saturation. 2.) The brightness value is handled by a slider below the Alpha Slider. It automatically paints the Alpha bar accordingly. 3.) Clicking on a new spot on the wheel, moves the node there and repaints the selected object accordingly. The next stage through this week will be adding functionality that if more than one objects on the canvas are selected, the wheel is painted with its respective nodes in the correct color areas. What shall ensue will be adding a inner class/data members of nodes to the color wheel with their appropriate events (dragging, selection, deselction, main_node etc). Your feedback is welcome. :) My development branch can be found at: lp:~moduli16/inkscape/recolor/ -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

1 0