Development Project Ideas - Revision history

JHofinger: /* Extensions */

2023-03-11T12:16:07Z

Extensions

← Older revision		Revision as of 12:16, 11 March 2023
Line 101:		Line 101:
	== Extensions ==		== Extensions ==

	=== ~~Cached styles / CSS ===~~		=== Moved to [[Google Summer of Code#P14. Cached styles for inkex]] and following sections ===
	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~~ [~~https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ 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 ===~~
	~~[https://gitlab.com/inkscape/extras/extensions-gcodetools/ 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~~

	~~# query maker spaces on their needs regarding gcodetools,~~
	~~# implement those needs together with unit tests,~~
	~~# improve the test coverage of Gcodetools,~~
	~~# 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:~~

	* [https://en.wikipedia.org/wiki/Cutting_stock_problem 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 [https://github.com/Jack000/SVGnest 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 ==		== Import/export projects ==

JHofinger at 21:32, 3 March 2023

2023-03-03T21:32:44Z

← Older revision		Revision as of 21:32, 3 March 2023
Line 123:		Line 123:
	* '''Import of CGM''' - old, but ISO standardized. Was supported once and dropped when the uniconvertor extension was removed for 1.0.		* '''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...		* '''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?		* 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'''		'''Skillset: Python, Test-driven development, ability to read technical documents, (depending on the format) some reverse engineering'''

JHofinger: /* Extensions */

2023-03-03T21:29:32Z

Extensions

← Older revision		Revision as of 21:29, 3 March 2023
Line 111:		Line 111:

	'''Skillset: Python, CSS'''		'''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?

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

	=== Gcodetools refactoring and documentation ===		=== Gcodetools refactoring and documentation ===
Line 129:		Line 144:

	'''Skillset: Python, computational geometry'''		'''Skillset: Python, computational geometry'''

	~~=== 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?

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

	== Import/export projects ==		== Import/export projects ==

JHofinger at 21:29, 3 March 2023

2023-03-03T21:29:11Z

← Older revision		Revision as of 21:29, 3 March 2023
Line 98:		Line 98:

	* [https://blueprints.launchpad.net/inkscape/+spec/lpe-blueprint More Live Path Effects] - There is a lengthy list of ideas to choose from here.		* [https://blueprints.launchpad.net/inkscape/+spec/lpe-blueprint 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 [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ 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'''

			=== Gcodetools refactoring and documentation ===
			[https://gitlab.com/inkscape/extras/extensions-gcodetools/ 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

			# query maker spaces on their needs regarding gcodetools,
			# implement those needs together with unit tests,
			# improve the test coverage of Gcodetools,
			# 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:

			* [https://en.wikipedia.org/wiki/Cutting_stock_problem 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 [https://github.com/Jack000/SVGnest 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 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?

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

	== Import/export projects ==		== Import/export projects ==

Jabiertxof: /* Slice toolbar items */

2020-10-10T18:34:35Z

Slice toolbar items

← Older revision		Revision as of 18:34, 10 October 2020
Line 94:		Line 94:
	* Remove XML prolog/DOCTYPE.		* Remove XML prolog/DOCTYPE.
	* Move sodipodi namespace items to Inkscape namespace.		* Move sodipodi namespace items to Inkscape namespace.

	~~== Slice toolbar items==~~
	~~[[File:Cuttool.png\|200px\|thumb\|right\|Example of result of the cut/eraser tool]]~~

	~~<u>Detailed Description</u>~~
	~~The goal is a toolbar item, called "slice" to slice items in a easy way.~~
	~~We check to convert strokes to path previously to cut, to avoid continuing with stroke thought cut-out item fills.<br />~~
	Maybe positioned in the path menu after bool operations, the selected items are sliced from topmost path, converting strokes to paths, duplicating fills and maybe apply to groups (there is some work in groups boolops from Martin Owens). <br />
	~~A lot of helper code is done yet in flatten branch (Alexander Brock lp:~inkscape+alexander/inkscape/flatten).<br />~~
	~~There are new Boolean operations, implemented but not used in trunk. We need to switch the division and flatten branch methods from Livarot to these new operations.<br />~~
	~~Another feature interesting is a second toolbar item "slice from guides" to get the guides over the selected item and use it as cut-out.<br />~~

	== Live Path Effects related ==		== Live Path Effects related ==

Patrick87: /* User interface */ Numeric input widgets with floating precision

2018-03-03T13:26:29Z

User interface: Numeric input widgets with floating precision

← Older revision		Revision as of 13:26, 3 March 2018
Line 33:		Line 33:
	* 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.		* 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.		* 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 [https://gitlab.com/inkscape/inkscape/merge_requests/200#note_58534331 can be included in GTK+4]).

	== Project infrastructure and platform support ==		== Project infrastructure and platform support ==

Patrick87: /* Project infrastructure and platform support */

2018-03-03T13:19:49Z

Project infrastructure and platform support

← Older revision		Revision as of 13:19, 3 March 2018
Line 38:		Line 38:
	* Migrate argument parsing to GOption and remove the dependency on popt. Update the devlibs version of Glib to one where this bug is fixed: [https://bugzilla.gnome.org/show_bug.cgi?id=522131]. Once this is done, port argument parsing to GOption.		* Migrate argument parsing to GOption and remove the dependency on popt. Update the devlibs version of Glib to one where this bug is fixed: [https://bugzilla.gnome.org/show_bug.cgi?id=522131]. Once this is done, port argument parsing to GOption.
	* [DONE] <s>Common build system for all platforms: Migrate the build system to CMake for all platforms and remove Autotools.</s>		* [DONE] <s>Common build system for all platforms: Migrate the build system to CMake for all platforms and remove Autotools.</s>
	* 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.		* [DONE] <s>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.</s>

	== Rendering Improvements ==		== Rendering Improvements ==

Tavmjong at 20:54, 18 February 2018

2018-02-18T20:54:03Z

← Older revision		Revision as of 20:54, 18 February 2018
Line 1:		Line 1:

			See also [[Projects]] and [[Refactoring projects]].
	==General==		==General==

Tavmjong: /* General */

2018-02-18T20:50:28Z

General

← Older revision		Revision as of 20:50, 18 February 2018
Line 3:		Line 3:

	* Improve startup time and initialization performance (i.e. improve font cache).		* Improve startup time and initialization performance (i.e. improve font cache).
	* 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.		* [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:		* Continue C++ migration:
	** Use Glib::ustring for UTF-8 data and std::string for filenames and raw byte strings instead of C-strings (char*).		** Use Glib::ustring for UTF-8 data and std::string for filenames and raw byte strings instead of C-strings (char*).
	** Replace uses of GList and GSList with STL containers.		** [Done] <s>Replace uses of GList and GSList with STL containers.</s>
	* 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.		* 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.

BryceHarrington: /* Object tree */ Move these to the Project's list Object Tree and General Codebase section

2018-02-18T20:36:20Z

Object tree: Move these to the Project's list Object Tree and General Codebase section

← Older revision		Revision as of 20:36, 18 February 2018
Line 23:		Line 23:
	** <tt>stroke(double line_width, LineJoin join, LineCap cap, double miter_limit)</tt>, which performs the stroke-to-path operation.		** <tt>stroke(double line_width, LineJoin join, LineCap cap, double miter_limit)</tt>, which performs the stroke-to-path operation.
	** <tt>dash(std::vector<double> const &dasharray)</tt>, which performs dashing.		** <tt>dash(std::vector<double> const &dasharray)</tt>, which performs dashing.

	~~== Object tree ==~~

	* 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.
	* 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.
	* Replace the print functions in the SPxxx classes with a generic "Visitor" pattern and port at least one export type (e.g. EMF, PDF, PS) to the new routines.

	== User interface ==		== User interface ==