Development Project Ideas

See also Projects and Refactoring projects.

General

• Improve startup time and initialization performance (i.e. improve font cache).
• [Done?] Improve icon cache: Convert the icon cache (widgets/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. GTK supports SVG icons, no need to convert to PNGs.
• Continue C++ migration:
  • Use Glib::ustring for UTF-8 data and std::string for filenames and raw byte strings instead of C-strings (char*).
  • [Done] Replace uses of GList and GSList with STL containers.
• 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 write data to memory without going through a temporary file.

XML tree

• 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.
• 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 the SAX parser, as this will make it easier.

2Geom geometry library

• 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.
• 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.
• Provide a quick bounding box routine for stroked paths.
• Boolean operations and stroking: Add methods to PathVector objects:
  • Set operators (& | - ^), which perform the relevant Boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm. The CGAL implementation is horribly broken and doesn't work; there is an implementation of the Greiner-Hormann algorithm in 2Geom now, but it's not robust and runs pretty slow.
  • stroke(double line_width, LineJoin join, LineCap cap, double miter_limit), which performs the stroke-to-path operation.
  • dash(std::vector<double> const &dasharray), which performs dashing.

User interface

• 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, consistent outlining / update preferences for all shapes, and editing more than one shape at once.
• Transformation Anchors
• Extend the Symbols dialog to include generic objects.
• Connector tool improvements - Expose new libavoid functionality: orthogonal routing, connector ports, curved connectors. (Mentor: Michael Wybrow)
• Fillet/Chamfer tool
• Provide more actions in the context menu depending on the content of the selection, e.g. show "Put on Path", "Flow into Frame" etc. when the selection contains the appropriate objects.
• When right-clicking a control point, show a transient dialog which would allow one to key in its coordinates.
• Numeric input widgets with floating precision (instead of fixed field width like offered by GtkSpinButton and our derived classes). Potentially create a general implementation that can be included in GTK+4).

Project infrastructure and platform support

• Migrate argument parsing to GOption and remove the dependency on popt. Update the devlibs version of Glib to one where this bug is fixed: [1]. Once this is done, port argument parsing to GOption.
• [DONE] Common build system for all platforms: Migrate the build system to CMake for all platforms and remove Autotools.
• [DONE] 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.

Rendering Improvements

• ICC Color Management for cairo outputs - Would allow Inkscape to produce CMYK PDFs and PSs with Cairo.
• 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.
• Pluggable renderers - allow writing rendering backends which use something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL.
• 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 implementing boolean operations and stroking. 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

Better SVG standard coverage

• Full SVG viewbox support
• Multiple Page support
• Improve SVG compliance. Current status of W3C test suite compliance.

SVG 2 and CSS3

See: SVG2.

This includes providing suitable GUI and SVG 1.1 fallbacks.

• Filling and Stroking
  • Stroke position Postponed to future SVG path module.
  • Stroke dash adjustment
  • Multiple fills Postponed to future spec (at CSS Working Group request).
  • Paint order (Rendering and GUI implemented, only Edge does not support property.)
  • Marker color matching stroke. (Rendering implemented.)
  • Vector Effects (non-destructive boolean-ops would be a good start)
  • CSS3 color support
  • CSS3 blend modes (Rendering implemented, needs GUI.)
• Paint servers
  • Solid-color support (Named colors, would deprecate the single-stop gradient approach we currently use)
  • Mesh gradient (Done.)
  • Hatched patterns Needs GUI.

• Text
  • CSS based text flow

• Misc
  • CSS3 2d and 3d transforms Partial browser support. Cairo 3d support in progress.

Note: Some of the above items are somewhat low hanging fruit and would need a few of them to make a good proposal, others alone are worthy of a full GSoC project.

Improve Inkscape SVG for use on Web

A proposal should fix most if not all of these problems:

• Fix "plain" SVG to not remove <script> section, etc.
• Add option to set viewbox attribute to Document Properties.
• Easily add/edit hyperlinks.
• Better CSS support.
• Option to add title to SVG (searchability and accessibility).
• Remove XML prolog/DOCTYPE.
• Move sodipodi namespace items to Inkscape namespace.

Live Path Effects related

• More Live Path Effects - There is a lengthy list of ideas to choose from here.

Extensions

Cached styles / CSS

When inkex, the Python library behind Inkscape's extension system, computes styles, this is relatively slow, especially for documents with either many style sheets or documents with many elements / highly nested documents. This is because for each element, the XPATH of each CSS rule is computed, and then it is checked whether the current element is in the XPATH result. Then, the same computation is repeated for the parent. Since Python is not very fast itself, such inefficiencies quickly make style evaluation unusable for big documents.

With this project, we would explore ways to speed up those computations, mainly using caching and more intelligent ways of evaluating CSS rules. Some approaches might be taken from a recent firefox refactoring.

Ideally, the caching will be tuned to support read-only (export), read-heavy (modify path), write-heavy (generate from path) and write-only (import) extensions, which have different caching needs.

The work should be done in a test-driven development approach.

Skillset: Python, CSS

Import and Export extensions

Inkscape is alway looking to improve compatibility! Some ideas of relevant file formats - each of them more than enough for one GSoC:

• Refactor our DXF input and output extensions, and expand support towards binary DXF
• Write an as-complete-as-possible EPS export, circumventing the internal information loss in ghostscript (EPS is still relevant for scientific papers, but more and more tools are dropping support, so this is a chance to grab market share - the results of Adobe Distiller are much better than ghostscripts.... )
• Rewrite the XAML importer in Python (currenly XSLT) to match the capabilities of the new XAML exporter (i.e. support for different target frameworks, better text support...) - would have to select carefully what to support (drawing primitives) and what not (control elements) - the boundary is not as clear-cut as it seems.
• Update the Synfig export to support the latest Synfig developments
• Import or export of TikZ. There are a few abandoned extensions out there (from which we can borrow), but it's very widely used in science - both import and export could serve an important function in the scientific workflow.
• Import of the proprietary fileformats of Affinity Design, Vectornator, Vectorstyler (especially the last two seem in their infancy and users at some point sit on a bunch of files that they can't open anymore because their SAAS model wasn't profitable) .
• Import of CGM - old, but ISO standardized. Was supported once and dropped when the uniconvertor extension was removed for 1.0.
• Python based EMF / WMF importer - the current (core Inkscape) C extension is unmaintained and Python would probably be the right way to get more collaboration on it. A lot of public archives sit on mountains of EMF files. Note that the Document Foundation recently did a lot of work properly importing those files, so we can learn from them / maybe even join forces...
• your favorite file format? - also have a look here: https://office.inkscape.org/nextcloud/index.php/s/Tq6cdDDGay6taCw

Skillset: Python, Test-driven development, ability to read technical documents, (depending on the format) some reverse engineering

Gcodetools refactoring and documentation

Gcodetools is a set of Inkscape extensions that deal with reading and creating Gcode files, mostly for use in laser cutters or plotters. For this project, ideally someone with a Makerspace background will

1. query maker spaces on their needs regarding gcodetools,
2. implement those needs together with unit tests,
3. improve the test coverage of Gcodetools,
4. write proper documentation for it. (doesn't really exist at the moment).

Skillset: Maker background / familiarity with the Maker community, Python

Packing / Nesting as an Inkscape extension

In this project, a set of packing / nesting algorithms will be implemented:

• Linear nesting is not too useful in SVG, but might be a good place to get acquainted with the problem. 2D cutting stock problem would be very interesting to have and would work great with the new multipage functionality.
• For efficient packing of free form objects, we might just re-implement SVGNest in Python. There are probably some more recent research papers which would be interesting to implement as a comparison.

Skillset: Python, computational geometry

Import/export projects

• Importing of 3D scene files in 16 file formats using Open Asset Import Library
• xar-to-svg converter - Converter for Xara Xtreme to Inkscape
• KML SVG translation - For use of Inkscape with Google Earth or Maps

Generic ideas

• Font editing and creation features, e.g. designing SVG fonts using styles
• kidscape - Condensed version of Inkscape aimed at young kids and small form factor devices
• Cutter control - Enable Inkscape's use with vinyl cutters.