Hey All,
We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1).
If you are interested in participating as a student please visit our page on Melange (2) 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.
Cheers, Josh
(1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape
On Mon, Feb 24, 2014 at 11:14:41AM -0800, Josh Andler wrote:
Hey All,
We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1).
If you are interested in participating as a student please visit our page on Melange (2) 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.
Cheers, Josh
(1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape
Here's also a bunch of good ideas Krzysztof posted several weeks back. Some of these may be a little too ambitious to do in a summer so would need scoped down.
1. Improve Icon Cache Convert the icon cache (icon.cpp) to create the PNGs with a directory structure and index file matching the icon theme specification. Use this to get rid of customized classes InkAction, SPIcon, and so on.
2. Remove dom/ directory This directory contains strange code which is barely used. The only class which is actually used is the URI class.
3. SAX parser Convert the current document parser from DOM to SAX, so that it creates our XML tree right away, instead of creating the libxml2 DOM tree, creating our tree to match it, then freeing the libxml2 tree. This should improve performance and allow more robust fixes for some problems.
4. Rewrite of Geom::PathVector and Geom::Path Change PathVector to be a real object instead of a std::vector of Path, so that it can have useful methods, similar to curves. Move the copy-on-write idiom to the PathVector object, rather than using it in the Path. Investigate whether it is possible to store subpath data in a more compact way and make the Curve objects only convenience facades. Right now, if the path has only linear segments, every point is stored twice. Apply the following renames to match SVG terminology: Path -> Subpath PathVector -> Path
5. Boolean operations and stroking Add methods to PathVector objects: a) Set operators (& | - ^), which perform the relevant boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm. b) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit), which performs the stroke-to-path operation. c) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit, std::vector<double> const &dasharray), which performs stroke-to-path with dashing.
6. Renderer improvements This is a big task which has several sub-tasks: a) Unify the interactive and non-interactive renderers. (It would be desirable to have one codebase, but we need to investigate a little more whether this is practical.) b) Pluggable renderers - allow writing rendering backends which use something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL. c) OpenGL renderer - implement an OpenGL 3.x+ canvas which would render Beziers using this method: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html Investigate whether this generalizes to S-basis and circular arcs. Since the described method does not handle stroking, this work depends on 5. Also check how OpenGL path rendering is implemented in Qt, since apparently the performance there is very good. http://zrusin.blogspot.com/2011/09/nv-path-rendering.html
7. Typed XML tree Improve XML tree so that it can store some attributes in parsed, binary form. The main target of this are the data URIs used to embed images, which could be stored as binary data only. This work should be done after completing task 3 (SAX parser), as this will make it easier.
8. Shape manipulators The idea here is to rewrite shape tools in the same paradigm as the node tool. Instead of storing all information about the shape in knots which differ only by their callbacks, allow to store information in a higher-level manipulator object. This would enable things like dragging the side of a rectangle and consistent outlining / update preferences for all shapes.
9. Improve the performance of layer visibility Right now, toggling layer visibility causes massive changes in the display tree, because the entire toggled layer is invalidated at the XML level. This results in very bad performance for an action which should nearly instantaneous. Improve the control flow so that only the visibility of the object representing the layer is turned off, but the remainder of the display and object tree is leaved alone.
10. Common build system for all platforms Migrate the build system to Waf for all platforms. Alternatively, if there are important technical reasons why Waf is not suitable, port all necessary features to the CMake build system and remove Autotools.
11. Remove SPCurve SPCurve is a thin wrapper around Geom::PathVector which exists for historical reasons. Its functionality should be added to PathVector, and SPCurve should be purged.
12. Use a different data structure for Inkscape::Selection Inkscape::Selection currently uses GSList as its data structure. This is suboptimal, since a very common operation is checking whether some object is selected. Change Inkscape::Selection so that its underlying structure is a boost::multi_index container which implements the same semantics as Java's LinkedHashSet.
13. Remove all use of GList and GSList These GLib data structures are poorly designed (they are simple lists without sentinels, leading to blunders such as O(N) performance when appending to a doubly-linked list) and not type-safe. Replace all uses with standard C++ containers or suitable Boost containers.
14. Box blur Currently we always use a very accurate method to compute the Gaussian blur filter. Add an alternate method which approximates Gaussian blur using three stacked box blurs (simple averages). This is detailed in the SVG 1.1 SE specification.
15. GTK3 on Windows Rebuild the Windows devlibs so that they contain GTK3. Make the Windows port work with them, possibly sending the appropriate patches to the GTK maintainers.
16. Migrate argument parsing to GOption and remove the dependency on popt Write test cases for this bug, so that the patches can be accepted into GLib: https://bugzilla.gnome.org/show_bug.cgi?id=522131 If this proves hard, simply apply the patch to the devlibs. Once this is done, port argument parsing to GOption.
17. Extension system improvements Refactor the extension API. Clean up the kludgy class hierarchy, possibly using multiple inheritance. Use GInputStream and GOutputStream as parameters instead of file paths, so that things like the clipboard can have
18. Robust ID handling Currently ID clash resolution is implemented as a giant switch over object types, listing every possible dependency. Replace this with virtual methods on objects, which provide information on what each object refers to. Improve behavior when a dependency of an object is deleted, and when IDs are changed / deleted from the XML editor.
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
That's worth knowing, I'll hack that up in my branch as I add the data uri support.
Martin,
I added Krzysztof's list to Inkscape GSOC wiki page.
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
On Mon, Feb 24, 2014 at 11:14:41AM -0800, Josh Andler wrote:
Hey All,
We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1).
If you are interested in participating as a student please visit our page on Melange (2) 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.
Cheers, Josh
(1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape
Here's also a bunch of good ideas Krzysztof posted several weeks back. Some of these may be a little too ambitious to do in a summer so would need scoped down.
- Improve Icon Cache
Convert the icon cache (icon.cpp) to create the PNGs with a directory structure and index file matching the icon theme specification. Use this to get rid of customized classes InkAction, SPIcon, and so on.
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
- SAX parser
Convert the current document parser from DOM to SAX, so that it creates our XML tree right away, instead of creating the libxml2 DOM tree, creating our tree to match it, then freeing the libxml2 tree. This should improve performance and allow more robust fixes for some problems.
- Rewrite of Geom::PathVector and Geom::Path
Change PathVector to be a real object instead of a std::vector of Path, so that it can have useful methods, similar to curves. Move the copy-on-write idiom to the PathVector object, rather than using it in the Path. Investigate whether it is possible to store subpath data in a more compact way and make the Curve objects only convenience facades. Right now, if the path has only linear segments, every point is stored twice. Apply the following renames to match SVG terminology: Path -> Subpath PathVector -> Path
- Boolean operations and stroking
Add methods to PathVector objects: a) Set operators (& | - ^), which perform the relevant boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm. b) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit), which performs the stroke-to-path operation. c) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit, std::vector<double> const &dasharray), which performs stroke-to-path with dashing.
- Renderer improvements
This is a big task which has several sub-tasks: a) Unify the interactive and non-interactive renderers. (It would be desirable to have one codebase, but we need to investigate a little more whether this is practical.) b) Pluggable renderers - allow writing rendering backends which use something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL. c) OpenGL renderer - implement an OpenGL 3.x+ canvas which would render Beziers using this method: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html Investigate whether this generalizes to S-basis and circular arcs. Since the described method does not handle stroking, this work depends on 5. Also check how OpenGL path rendering is implemented in Qt, since apparently the performance there is very good. http://zrusin.blogspot.com/2011/09/nv-path-rendering.html
- Typed XML tree
Improve XML tree so that it can store some attributes in parsed, binary form. The main target of this are the data URIs used to embed images, which could be stored as binary data only. This work should be done after completing task 3 (SAX parser), as this will make it easier.
- Shape manipulators
The idea here is to rewrite shape tools in the same paradigm as the node tool. Instead of storing all information about the shape in knots which differ only by their callbacks, allow to store information in a higher-level manipulator object. This would enable things like dragging the side of a rectangle and consistent outlining / update preferences for all shapes.
- Improve the performance of layer visibility
Right now, toggling layer visibility causes massive changes in the display tree, because the entire toggled layer is invalidated at the XML level. This results in very bad performance for an action which should nearly instantaneous. Improve the control flow so that only the visibility of the object representing the layer is turned off, but the remainder of the display and object tree is leaved alone.
- Common build system for all platforms
Migrate the build system to Waf for all platforms. Alternatively, if there are important technical reasons why Waf is not suitable, port all necessary features to the CMake build system and remove Autotools.
- Remove SPCurve
SPCurve is a thin wrapper around Geom::PathVector which exists for historical reasons. Its functionality should be added to PathVector, and SPCurve should be purged.
- Use a different data structure for Inkscape::Selection
Inkscape::Selection currently uses GSList as its data structure. This is suboptimal, since a very common operation is checking whether some object is selected. Change Inkscape::Selection so that its underlying structure is a boost::multi_index container which implements the same semantics as Java's LinkedHashSet.
- Remove all use of GList and GSList
These GLib data structures are poorly designed (they are simple lists without sentinels, leading to blunders such as O(N) performance when appending to a doubly-linked list) and not type-safe. Replace all uses with standard C++ containers or suitable Boost containers.
- Box blur
Currently we always use a very accurate method to compute the Gaussian blur filter. Add an alternate method which approximates Gaussian blur using three stacked box blurs (simple averages). This is detailed in the SVG 1.1 SE specification.
- GTK3 on Windows
Rebuild the Windows devlibs so that they contain GTK3. Make the Windows port work with them, possibly sending the appropriate patches to the GTK maintainers.
- Migrate argument parsing to GOption and remove the dependency on popt
Write test cases for this bug, so that the patches can be accepted into GLib: https://bugzilla.gnome.org/show_bug.cgi?id=522131 If this proves hard, simply apply the patch to the devlibs. Once this is done, port argument parsing to GOption.
- Extension system improvements
Refactor the extension API. Clean up the kludgy class hierarchy, possibly using multiple inheritance. Use GInputStream and GOutputStream as parameters instead of file paths, so that things like the clipboard can have
- Robust ID handling
Currently ID clash resolution is implemented as a giant switch over object types, listing every possible dependency. Replace this with virtual methods on objects, which provide information on what each object refers to. Improve behavior when a dependency of an object is deleted, and when IDs are changed / deleted from the XML editor.
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Feb 25, 2014, at 8:58 AM, Martin Owens wrote:
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
That's worth knowing, I'll hack that up in my branch as I add the data uri support.
Actually the intent of this one had been explained to others in the past. The dom directory was done in preparation of improving the extension system by providing a live DOM interface to plugins. We've even had members of the SVG and XML committees review and endorse the approach.
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
On Wed, 2014-02-26 at 08:32 -0800, Jon Cruz wrote:
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
Sounds like we were all on the wrong page with this one. Several developers seemed to think dom was on it's way out.
Does this mean uri.cpp / uri.h should be depricated? Should uri.cpp shift from using libxml to dom? What does the css parsing mean for libcroco?
Why do we have a giant blob of code, shouldn't it be a library that many people could take advantage of?
Thank fluctuations I put it in a branch though.
Martin,
Hi Everybody,
Is there a possibility from either within Inkscape or by using an external script (PHP, Ruby, Python, Bash, TurboPascal ;-) ) to convert every layer in Inkscape to a separate SVG file? Preferably, using the name of the layer as the file name.
I tried some Google research, but all I found were references to the possibility of extracting bitmaps from Inkscape-layers.
Thanks in advance,
Maarten
Hi Maarten,
I've wanted this functionality too in the past... so I've built it. You can download an extension to save an svg as a collection of svg files here:
http://sexternalharddrive.com/tar_layers_inkscape_extension.1.0.tar.gz
It outputs a tar file (because we can only output a file, not to a directory). I've also committed this to trunk so it'll be available for everyone in the next version of inkscape.
Martin,
On Thu, 2014-02-27 at 09:13 +0100, M.H. van der velde wrote:
Hi Everybody,
Is there a possibility from either within Inkscape or by using an external script (PHP, Ruby, Python, Bash, TurboPascal ;-) ) to convert every layer in Inkscape to a separate SVG file? Preferably, using the name of the layer as the file name.
I tried some Google research, but all I found were references to the possibility of extracting bitmaps from Inkscape-layers.
Thanks in advance,
Maarten
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Hi Martin,
Thanks for your script. It should do exactly what I need, but unfortunately, I can’t test it. I installed it, found it under ‘save as’ and tried running it...
…and ran into the notorious LibXML problem — that I tried to fixe earlier on to use the beautiful plethora of extensions… :(
I tried many of the ‘solutions’ one finds by googling, but none of them worked. It might of course be that one ‘solutions’ ruins the other.
( I tried: running a special Mac version of inkscape (Mac OS X Mountain Lion x86_64 packaging of 0.48.4) Works really nicely, fixes a lot of Mac issues, except, for me, this one) Chaning the inkscape.bin file (line 32, export VERSIONER_PYTHON_VERSION=2.7 to export VERSIONER_PYTHON_VERSION=2.6) installing LibXML using home-brew. installing Inkscape using home-brew)
Thanks again!
Maarten
On 01 Mar 2014, at 04:41, Martin Owens <doctormo@...155...> wrote:
Hi Maarten,
I've wanted this functionality too in the past... so I've built it. You can download an extension to save an svg as a collection of svg files here:
http://sexternalharddrive.com/tar_layers_inkscape_extension.1.0.tar.gz
It outputs a tar file (because we can only output a file, not to a directory). I've also committed this to trunk so it'll be available for everyone in the next version of inkscape.
Martin,
On Thu, 2014-02-27 at 09:13 +0100, M.H. van der velde wrote:
Hi Everybody,
Is there a possibility from either within Inkscape or by using an external script (PHP, Ruby, Python, Bash, TurboPascal ;-) ) to convert every layer in Inkscape to a separate SVG file? Preferably, using the name of the layer as the file name.
I tried some Google research, but all I found were references to the possibility of extracting bitmaps from Inkscape-layers.
Thanks in advance,
Maarten
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
My use-case might be of interest to other Inkscape users as well (especially those who have a function LibXML library :-) )
The reason I would like this functionality is so I can create -a library of icons in ONE file, -export them all to separate SVG-files (with meaningful names) -and import them into the icomoon.io web-app that -transforms the icons into an icon font :D
Maarten
Inkscpae is brilliant tool for making icons, I prefer it much above Illustrator.
On 01 Mar 2014, at 04:41, Martin Owens <doctormo@...155...> wrote:
Hi Maarten,
I've wanted this functionality too in the past... so I've built it. You can download an extension to save an svg as a collection of svg files here:
http://sexternalharddrive.com/tar_layers_inkscape_extension.1.0.tar.gz
It outputs a tar file (because we can only output a file, not to a directory). I've also committed this to trunk so it'll be available for everyone in the next version of inkscape.
Martin,
On Thu, 2014-02-27 at 09:13 +0100, M.H. van der velde wrote:
Hi Everybody,
Is there a possibility from either within Inkscape or by using an external script (PHP, Ruby, Python, Bash, TurboPascal ;-) ) to convert every layer in Inkscape to a separate SVG file? Preferably, using the name of the layer as the file name.
I tried some Google research, but all I found were references to the possibility of extracting bitmaps from Inkscape-layers.
Thanks in advance,
Maarten
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 2014-03-07 09:45 +0100, M.H. van der velde wrote:
Hi Martin,
Thanks for your script. It should do exactly what I need, but unfortunately, I can’t test it. I installed it, found it under ‘save as’ and tried running it...
…and ran into the notorious LibXML problem — that I tried to fixe earlier on to use the beautiful plethora of extensions… :(
I tried many of the ‘solutions’ one finds by googling, but none of them worked. It might of course be that one ‘solutions’ ruins the other.
Could well be.
Assuming your system Python version is the one provided (and maintained) by Apple and has not been tinkered with: download a fresh copy of the official Inkscape package (0.48.2) from inkscape.org and follow the instructions here: https://bugs.launchpad.net/inkscape/+bug/819209/comments/17
Cheers, V
Su_V, Martin,
Thank you both for your help and suggestions. I finaly got it working. Great! This is really helpful.
Martin, I do not know if it’s on purpose, but hidden layers do not get exported. I can understand your choice here, but when working with lot’s of layers, it might prove impractical, as it’s not possible to hide/show all layers in Inkscape. But, again, thanks a lot!
Maarten
On Fri, 2014-03-07 at 14:13 +0100, M.H. van der velde wrote:
Martin, I do not know if it’s on purpose, but hidden layers do not get exported. I can understand your choice here, but when working with lot’s of layers, it might prove impractical, as it’s not possible to hide/show all layers in Inkscape. But, again, thanks a lot!
There's no code that checks to see if layers are visible or not. But maybe something else is happening.
Martin,
On 2014-03-07 14:13 +0100, M.H. van der velde wrote:
(...) but when working with lot’s of layers, it might prove impractical, as it’s not possible to hide/show all layers in Inkscape.
Check the context menu of the selected layer in the Layers dialog ...
Cheers, V
…and it says “hide other layers”.
Thanks! Missed that one completely. And I *realy* searched for it! :D
On 07 Mar 2014, at 15:53, su_v <suv-sf@...16...> wrote:
On 2014-03-07 14:13 +0100, M.H. van der velde wrote:
(...) but when working with lot’s of layers, it might prove impractical, as it’s not possible to hide/show all layers in Inkscape.
Check the context menu of the selected layer in the Layers dialog ...
Cheers, V
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.cl... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
participants (7)
-
Bryce Harrington -
Jon Cruz -
Josh Andler -
M.H. van der velde -
Martin Owens -
su_v -
Tavmjong Bah