Difference between revisions of "Google Summer of Code"

From Inkscape Wiki
Jump to navigation Jump to search
(48 intermediate revisions by 8 users not shown)
Line 1: Line 1:
<div style="max-width:70em; margin-left: auto; margin-right: auto">
= Welcome to Inkscape! =
= Welcome to Inkscape! =


Line 12: Line 13:


* Google program information:
* Google program information:
** [https://www.google-melange.com/gsoc/homepage/google/gsoc2014 Home page].
** [https://summerofcode.withgoogle.com/ Home page].
** Summer of Code Application form. Applications open at 19:00 UTC on March 10th.
** Summer of Code Application form. Applications open at 16:00 UTC on March 12th.


* Inkscape-specific information:
* Inkscape-specific information:
** [[SOC Application Template]].
** [[SOC Application Template]].
** [[Roadmap | Inkscape Roadmap]] - to see our overall objectives.
** [[Roadmap | Inkscape Roadmap]] - to see our overall objectives.
** [[Projects | Inkscape Development Project Ideas]] - broader list of development ideas.
** [[SOC Writing Project Proposals]] - some guidelines for proposals.
** [[SOC Writing Project Proposals]] - some guidelines for proposals.
** [[SOC Selection Criteria]] - how we rate applications.
** [[SOC Selection Criteria]] - how we rate applications.


'''Student Applications for GSoC 2014 must be submitted to the GSoC site by 19:00 UTC on March 21st 2014.'''
'''Student Applications for GSoC 2018 must be submitted to the GSoC site by 16:00 UTC on March 27th 2018.'''


= The "two patches" rule =
= The "two patches" rule =
Line 50: Line 52:
= Suggested Project Ideas =
= Suggested Project Ideas =


[[Development Project Ideas]]
The following is a list of formal project suggestions, but do not feel limited to only these - some of our best contributions have been unique ideas that students had in mind from other sources!


== Template ==
See also [[Development Project Ideas]], [[Refactoring projects]], [[Projects]], and https://blueprints.launchpad.net/inkscape/


Brief description
==P1. Better CSS Style Sheet Support==


* Estimation of difficulty:
Enhance Inkscape's support for CSS style sheets.
* Potential mentors:
* Programming skills needed:
* Prerequisites:


{More detailed description}
* Estimation of difficulty: Moderately hard
* Potential mentors: Tavmjong Bah
* Programming skills needed:  C++
* Prerequisites: Experience with CSS style sheets.


{Use cases}
<u>Detailed Description</u>


{Related materials}
Inkscape has rudimentary support for CSS style sheets that can read and parse one internal style sheet. A 2016 GSoC project added a simple style dialog that can create and modify the internal style sheet. The dialog is very limited and is not intuitive to use. This project will extend the usefulness of that dialog by making it more user friendly and by extending its functionality. The use of CSS classes should eventually replace the Selection Set dialog.


Stretch goals include:


* Support external style sheets. DONE
* Support multiple internal style sheets.
* Support CSS 3 selectors. DONE GSoC 2017
* Support parsing of 'font-face'. DONE


==General==
<u>Use Cases</u>


* Improve startup time and initialization performance (i.e. improve font cache).
* Support externally created SVGs.
* 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.
* Producing better SVGs for the Web.
* Continue C++ migration:
* Changing style on multiple objects at once (palettes).
** 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.
* 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.
* 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 ==
<u>Related Material</u>


* 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.
* [https://www.w3.org/TR/CSS2/ CSS 2 Specification]
* 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.
* [https://www.w3.org/TR/css-2015/ CSS 2015 Snapshot]


== 2Geom geometry library ==
==P3. Slice toolbar items==
[[File:Cuttool.png|200px|thumb|right|Example of result of the cut/eraser tool]]
Add slicing Live Path Effect (LPE)
* Estimation of difficulty: Moderately hard
* Potential mentors: Jabier Arraiza (Spanish, some English)
* Programming skills needed:  C++


* Rewrite of Geom::PathVector and Geom::Path:
<u>Detailed Description</u>
** Change PathVector to be a real object instead of a std::vector of Path, so that it can have useful methods, similar to curves.
The goal is a LPE, to slice items.<br />
** Move the copy-on-write idiom to the PathVector object, rather than using it in the Path.
It accept a path parameter as cutter.<br />
** 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.
The effect create pieces by the split path.<br />
** Apply the following renames to match SVG terminology:
Add a toggle button to pause cutting on effect to allow move pieces cutted.<br />
*** Path -> Subpath
Add a option to reset pieces (reload LPE with the current path parameter).<br />
*** PathVector -> Path
We have the code of mirror symmetry LPE and rotate copies LPE as reference.<br />
* 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.
Also we can force or better ask to convert strokes to path previously to apply the effect (one line command, but we need advert is a destructive LPE)<br />
* Provide a quick bounding box routine for stroked paths.
Study autogenerate a HTML image map code linking with the Item LPE parameter to another object in hover state.
* Boolean operations and stroking: Add methods to PathVector objects:
<br />
** Set operators (& | - ^), which perform the relevant boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm.
<u>Use Cases</u>
** <tt>stroke(double line_width, LineJoin join, LineCap cap, double miter_limit)</tt>, which performs the stroke-to-path operation.
* Better item slicing.
** <tt>stroke(double line_width, LineJoin join, LineCap cap, double miter_limit, std::vector<double> const &dasharray)</tt>, which performs stroke-to-path with dashing.
* Split a item and use for example on PNG export option export as separate objects.


== Object tree ==
==P4. SVG 2 Text Support (Done in GSOC 2017)==


* 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.
* Estimation of difficulty: Hard
* 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.
* Potential mentors: Tavmjong Bah
* 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.
* Programming skills needed: C++
* Prerequisites: Familiarity with text layout. Knowledge of CSS.


== User interface ==
<u>Detailed Description</u>
* 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.
* [https://blueprints.launchpad.net/inkscape/+spec/transformation-anchors Transformation Anchors]
* Extend the Symbols dialog to include generic objects.
* [https://blueprints.launchpad.net/inkscape/+spec/inkscape-connectors Connector tool improvements] - Expose new libavoid functionality: orthogonal routing, connector ports, curved connectors. (Mentor: Michael Wybrow)
* [https://blueprints.launchpad.net/inkscape/+spec/fillet-tool 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.
* Provide a way to resize the page directly on the canvas, instead of keying in numbers in the Document Properties dialog.


== Project infrastructure and platform support ==
Inkscape currently has a non-compliant flowed text feature (based on SVG 1.2 which was never adopted) that needs to be made compatible with both SVG2 and SVG 1.1. This project is to re-implement the flowed text feature within Inkscape to be SVG2 compliant and to have a proper SVG 1.1 fallback. In addition to the flowed text itself as it exists within Inkscape, SVG2 adds new formatting features including shape-margin and shape-padding, shape-inside and shape-outside, exclusions, additional white-space control settings, pre-wrap, pre-line, etc.


* 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.
<u>Use Cases</u>
* 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.
* Proper text flow into rectangles and other shapes.
* 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 ==
<u>Related Material</u>
* [https://svgwg.org/svg2-draft/text.html Current draft of SVG 2 text specification.]


* [https://blueprints.launchpad.net/inkscape/+spec/icc-for-cairo ICC Color Management for cairo outputs] - Would allow Inkscape to produce CMYK PDFs and PSs with Cairo. <!-- Isn't this more of a Cairo project? -->
==P5. UI-Free Inkscape ==
* 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 ==
* Estimation of difficulty: Moderate
* Potential mentors: Marc Jeanmougin
* Programming skills: C++, CMake
* Prerequisites: Minimal knowledge of build systems


* Full SVG viewbox support
<u>Detailed Description</u>
* [[multipage | Multiple Page support]]
Inkscape currently builds with X11 and gtk and a lot of graphical dependencies. But since it is allowed to run in commandline, and there are controlled environments (servers) that use it to convert svg to png and to perform actions, there should be no need to force it to build with those. The main goal of this project is to add a WITH_GUI compilation flag that when OFF, does *not* link Inkscape with any graphical dependency. Then action verbs should be checked and made independent from the gui (one should be able to use any action modifying the svg in --no-gui mode, which is not currently the case).  
* Improve SVG compliance. [http://tavmjong.free.fr/INKSCAPE/W3C_SVG_1.1F2/harness/htmlInkscapeApproved/index.html Current status of W3C test suite compliance].


=== SVG 2 and CSS3 ===
Stretch goal may include the transformation of said verbs to Gio::Action regular actions to ease gtk3 handling, and/or no-gui performance optimizations (currently Inkscape actions in commandline are slower than with gui).


See: [[SVG2]].
<u>Use cases</u>
* Server installs, scripts


This includes providing suitable GUI and SVG 1.1 fallbacks.


* Filling and Stroking
** [http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position Stroke position]
** [http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment Stroke dash adjustment]
** [https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint Multiple fills]
** [https://svgwg.org/svg2-draft/painting.html#PaintOrder Paint order] (Rendering alread implemented, needs GUI and fallback.)
** Marker color matching stroke.
** Vector Effects (non-destructive boolean-ops would be a good start)
** [http://www.w3.org/TR/css3-color/ CSS3 color support]
** [http://dev.w3.org/fxtf/compositing-1/ CSS3 blend modes]


* Paint servers
==P6. Refactoring==
** [https://svgwg.org/svg2-draft/pservers.html#SolidColors Solid-color support] (Named colors, would deprecate the single-stop gradient approach we currently use)
* Estimation of difficulty: Moderate
** [https://svgwg.org/svg2-draft/pservers.html#MeshGradients Mesh gradient] (Basic implementation done, needs refinement and fallback.)
* Potential mentors: Tavmjong Bah
** [https://svgwg.org/svg2-draft/pservers.html#Hatches Hatched patterns]
* Programming skills: C++
* Prerequisites: proficient C++.


* Text
<u>Detailed Description</u>
** [https://svgwg.org/svg2-draft/text.html CSS based text flow]
Inkscape began life as the C program Sodipodi. Sodipodi was mostly the work of one person who had a clear vision of how the code should work. A major motivation of the Inkscape fork was to allow others to easily contribute to development. This resulted in rapid development but at a cost: the code has become much messier and now lacks a clear vision. This project is to work on refactoring the code. Refactoring can take many forms. It could be creating a better directory structure with README's that describe the purpose and function of the code in each directory. This would include rewriting code to reduce dependencies across directories (which would help, for example, in achieving a headless version of Inkscape). It could be the continued transition from C to C++ which often results in major reductions in the number of code lines. Or it could be identifying and eliminating redundant code. Refactoring is an important skill of which many books have been written. Here's a chance to gain valuable experience!


* Misc
==P7. Polyfills ==
** [http://www.w3.org/TR/css3-transforms/ CSS3 2d and 3d transforms]
* Estimation of difficulty: Variable
* Potential mentors: Tavmjong Bah
* Programming skills: JavaScript
* Prerequisites: Experience in web development.


<u>Detailed Description</u>
Many features of SVG 2 have yet to (and may never) make it into browsers. We can support those features by writing <i>polyfills</i> which implement missing functionality using JavaScript.


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.
==P8. Move from LivePathEffects to LiveEffects ==
* Estimation of difficulty: Hard
* Potential mentors: Jabier Arraiza (Spanish, some English)
* Programming skills: C++
* Prerequisites: Experience managing bitmaps
<u>Detailed Description</u>
Live Path Effects are non destructive effects applied to paths and shapes standalone or inside a group.<br />
This is done keepeng a reference to the original data to reaply when needed.<br />
But ignore text and image elements.<br />
Things to do:
* Refactor LPE system to rename it to LE.
* Study add image, text, both and maybe others SVG elements to the LE system.
* Create/adapt minimun one LPE for each new type of element acepted as reference. Suggestion Perspective-Envelope.
<u>Use cases</u>
* Apply live effects to images and text based in C++ code in a non destructive way: Slice, Mirror; Rotate, Perspective... even in groups with mixed elements types.


=== Improve Inkscape SVG for use on Web ===
==P9. Path Library Improvements ==
* Estimation of difficulty: Hard
* Potential mentors: Tavmjong Bah, KK
* Programming skills: C++
* Prerequisites: Strong math skills, specifically in geometry.
<u>Detailed Description</u>
Inkscape relies on two geometry libraries for path manipulations: lib2geom and livarot. lib2geom is a generic modern library written specifically with Inkscape in mind. lib2geom is missing some functionality that Inkscape requires and that is found in livarot. This project is to move that functionality into lib2geom (or into separate files) using lib2geom path descriptions.
Specifically, the functionality needed is
* Path offset/inset functions.
* Path simplify.
* Stroke to path function.
* Line scanning (used for flowing text into a shape).


A proposal should fix most if not all of these problems:
==P10. Your project ==
* Estimation of difficulty: Variable
* Potential mentors: Marc Jeanmougin
* Programming skills: usually C++
* Prerequisites: good ideas


* Fix "plain" SVG to not remove <script> section, etc.
<u>Detailed Description</u>
* Add option to set viewbox attribute to Document Properties.
The most successful GSoC we had in the past were students coming with their own past, use cases and ideas for Inkscape. Many basic tools like 3d cubes or connectors you can see in Inkscape now have been brought by brilliant people (like you) with ideas. If we think that your project fits with Inkscape (ie: has its place with a vector graphic editor), we can help you refining your ideas and help bring shiny new stuff to life!
* 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 ==
<u>Use cases</u>
 
* Amaze us!
* [https://blueprints.launchpad.net/inkscape/+spec/lpe-blueprint More Live Path Effects] - There is a lengthy list of ideas to choose from here.
 
<!-- All of these seem to be low priority for GSoC
 
== Import/export projects ==
 
* Importing of 3D scene files in 16 file formats using [http://assimp.sourceforge.net/ Open Asset Import Library]
* [https://blueprints.launchpad.net/inkscape/+spec/xar-to-svg-converter xar-to-svg converter] - Converter for Xara Xtreme to Inkscape
* [https://blueprints.launchpad.net/inkscape/+spec/kml-svg-translation KML SVG translation] - For use of Inkscape with Google Earth or Maps
 
 
== Generic ideas ==
 
* Font editing and creation features, e.g. [https://blueprints.launchpad.net/inkscape/+spec/designing-svg-fonts-using-styles designing SVG fonts using styles]
* [https://blueprints.launchpad.net/inkscape/+spec/kidscape-project kidscape] - Condensed version of Inkscape aimed at young kids and small form factor devices
* [https://blueprints.launchpad.net/inkscape/+spec/cutter-control Cutter control] - Enable Inkscape's use with vinyl cutters.
-->
 
Please do not feel limited to the above ideas - some of our best contributions have been unique ideas that students had in mind from other sources!
 
For more ideas, please see https://blueprints.launchpad.net/inkscape/


= Successful SOC Projects from Previous Years =
= Successful SOC Projects from Previous Years =
Line 227: Line 227:
** A test suite
** A test suite
* 2009
* 2009
** [[GSoC 2009 Node Tool Rewrite|Node tool rewrite]]
** [[GSoC2009 Node Tool Rewrite|Node tool rewrite]]
** D-Bus scripting API
** D-Bus scripting API
** Connector tool improvements
** Connector tool improvements
Line 250: Line 250:
* 2014
* 2014
** Better Support for SVG Paints
** Better Support for SVG Paints
** Robust Boolean and Stroking Operations for 2Geom  
** Robust Boolean and Stroking Operations for 2Geom
* 2016
** [[GSoC 2016 Better data structure for selections|Better data structure for selections]]
** [[Style Editor|CSS Style Sheet Editor]]
* 2017
** SVG 2 Text Support
** Better CSS Style Sheet Support
[[Category:Developer Documentation]]
[[Category:Developer Documentation]]
</div>

Revision as of 01:56, 20 March 2018

Welcome to Inkscape!

For quite a few years Inkscape has been successfully participating in Google Summer of Code.

GSoC is a program where Google funds the development of specific features in open source software by university students. You don't need to be a Computer Science student to apply. Features to be developed are picked by Inkscape administrators from the pool of proposals submitted by students.

We've mentored about half a dozen students a year since GSoC started. Many students enjoyed their work and continue to be involved; perhaps your mentor will be a past GSoC student! We have a high rate of acceptance of student code into the core codebase. Indeed, GSoC projects have been a key source of some of Inkscape's best features in the past several releases.

If you are interested in joining us this summer, it is time to get your proposal ready. You can choose a proposal from our list of suggestions or come up with one of your own. In either either case, you must give us a detailed outline of what you plan to do. It is highly recommended that you discuss your idea as early as possible with Inkscape developers. They not only can give you guidance as you flesh out your proposal but ultimately you must convince them that you can do the work planned in the time allotted.

Student Applications

  • Google program information:
    • Home page.
    • Summer of Code Application form. Applications open at 16:00 UTC on March 12th.

Student Applications for GSoC 2018 must be submitted to the GSoC site by 16:00 UTC on March 27th 2018.

The "two patches" rule

We require two patches from each potential GSoC student, before accepting the student for GSoC participation (it is the same requirement as for obtaining rights to commit changes to the Bazaar code repository). The reason for this requirement is that you can show us that you have succeeded in building Inkscape on your PC, and that you have understood a little piece of Inkscape's code and are able to improve it. Inkscape is a large project, and you really should not try to understand all the code. Many (all?) developers know only parts of the program code! You can join our jabber/IRC channel and ask developers for help.

Suggested "easy" bug fixes or improvements

To get you started on Inkscape development, you can find (probably) easy-to-fix bugs or small improvements that require very little knowledge of the whole program by searching our bug-tracker for bugs tagged with 'easy-fix'.

Performance Evaluation

GSoC has two formal evaluation points, at the mid-term and at the end. These evaluations determine if you receive the stipend from Google. In order to receive a pass for the evaluations you will need to show adequate progress toward your project's goals.

To help you meet your goals and so that your mentor can better evaluate your progress you need to:

  • Have frequent, public discussions of your progress. (Don't rely on just your mentor for advice.)
  • Have a public Inkscape branch for your code to which you commit regularly.
  • Give weekly status reports.

For the final pass, you will normally be required to merge your code into Inkscape trunk.

Remember: we want you to succeed!

Suggested Project Ideas

The following is a list of formal project suggestions, but do not feel limited to only these - some of our best contributions have been unique ideas that students had in mind from other sources!

See also Development Project Ideas, Refactoring projects, Projects, and https://blueprints.launchpad.net/inkscape/

P1. Better CSS Style Sheet Support

Enhance Inkscape's support for CSS style sheets.

  • Estimation of difficulty: Moderately hard
  • Potential mentors: Tavmjong Bah
  • Programming skills needed: C++
  • Prerequisites: Experience with CSS style sheets.

Detailed Description

Inkscape has rudimentary support for CSS style sheets that can read and parse one internal style sheet. A 2016 GSoC project added a simple style dialog that can create and modify the internal style sheet. The dialog is very limited and is not intuitive to use. This project will extend the usefulness of that dialog by making it more user friendly and by extending its functionality. The use of CSS classes should eventually replace the Selection Set dialog.

Stretch goals include:

  • Support external style sheets. DONE
  • Support multiple internal style sheets.
  • Support CSS 3 selectors. DONE GSoC 2017
  • Support parsing of 'font-face'. DONE

Use Cases

  • Support externally created SVGs.
  • Producing better SVGs for the Web.
  • Changing style on multiple objects at once (palettes).

Related Material

P3. Slice toolbar items

Example of result of the cut/eraser tool

Add slicing Live Path Effect (LPE)

  • Estimation of difficulty: Moderately hard
  • Potential mentors: Jabier Arraiza (Spanish, some English)
  • Programming skills needed: C++

Detailed Description The goal is a LPE, to slice items.
It accept a path parameter as cutter.
The effect create pieces by the split path.
Add a toggle button to pause cutting on effect to allow move pieces cutted.
Add a option to reset pieces (reload LPE with the current path parameter).
We have the code of mirror symmetry LPE and rotate copies LPE as reference.
Also we can force or better ask to convert strokes to path previously to apply the effect (one line command, but we need advert is a destructive LPE)
Study autogenerate a HTML image map code linking with the Item LPE parameter to another object in hover state.
Use Cases

  • Better item slicing.
  • Split a item and use for example on PNG export option export as separate objects.

P4. SVG 2 Text Support (Done in GSOC 2017)

  • Estimation of difficulty: Hard
  • Potential mentors: Tavmjong Bah
  • Programming skills needed: C++
  • Prerequisites: Familiarity with text layout. Knowledge of CSS.

Detailed Description

Inkscape currently has a non-compliant flowed text feature (based on SVG 1.2 which was never adopted) that needs to be made compatible with both SVG2 and SVG 1.1. This project is to re-implement the flowed text feature within Inkscape to be SVG2 compliant and to have a proper SVG 1.1 fallback. In addition to the flowed text itself as it exists within Inkscape, SVG2 adds new formatting features including shape-margin and shape-padding, shape-inside and shape-outside, exclusions, additional white-space control settings, pre-wrap, pre-line, etc.

Use Cases

  • Proper text flow into rectangles and other shapes.

Related Material

P5. UI-Free Inkscape

  • Estimation of difficulty: Moderate
  • Potential mentors: Marc Jeanmougin
  • Programming skills: C++, CMake
  • Prerequisites: Minimal knowledge of build systems

Detailed Description Inkscape currently builds with X11 and gtk and a lot of graphical dependencies. But since it is allowed to run in commandline, and there are controlled environments (servers) that use it to convert svg to png and to perform actions, there should be no need to force it to build with those. The main goal of this project is to add a WITH_GUI compilation flag that when OFF, does *not* link Inkscape with any graphical dependency. Then action verbs should be checked and made independent from the gui (one should be able to use any action modifying the svg in --no-gui mode, which is not currently the case).

Stretch goal may include the transformation of said verbs to Gio::Action regular actions to ease gtk3 handling, and/or no-gui performance optimizations (currently Inkscape actions in commandline are slower than with gui).

Use cases

  • Server installs, scripts


P6. Refactoring

  • Estimation of difficulty: Moderate
  • Potential mentors: Tavmjong Bah
  • Programming skills: C++
  • Prerequisites: proficient C++.

Detailed Description Inkscape began life as the C program Sodipodi. Sodipodi was mostly the work of one person who had a clear vision of how the code should work. A major motivation of the Inkscape fork was to allow others to easily contribute to development. This resulted in rapid development but at a cost: the code has become much messier and now lacks a clear vision. This project is to work on refactoring the code. Refactoring can take many forms. It could be creating a better directory structure with README's that describe the purpose and function of the code in each directory. This would include rewriting code to reduce dependencies across directories (which would help, for example, in achieving a headless version of Inkscape). It could be the continued transition from C to C++ which often results in major reductions in the number of code lines. Or it could be identifying and eliminating redundant code. Refactoring is an important skill of which many books have been written. Here's a chance to gain valuable experience!

P7. Polyfills

  • Estimation of difficulty: Variable
  • Potential mentors: Tavmjong Bah
  • Programming skills: JavaScript
  • Prerequisites: Experience in web development.

Detailed Description Many features of SVG 2 have yet to (and may never) make it into browsers. We can support those features by writing polyfills which implement missing functionality using JavaScript.

P8. Move from LivePathEffects to LiveEffects

  • Estimation of difficulty: Hard
  • Potential mentors: Jabier Arraiza (Spanish, some English)
  • Programming skills: C++
  • Prerequisites: Experience managing bitmaps

Detailed Description Live Path Effects are non destructive effects applied to paths and shapes standalone or inside a group.
This is done keepeng a reference to the original data to reaply when needed.
But ignore text and image elements.
Things to do:

  • Refactor LPE system to rename it to LE.
  • Study add image, text, both and maybe others SVG elements to the LE system.
  • Create/adapt minimun one LPE for each new type of element acepted as reference. Suggestion Perspective-Envelope.

Use cases

  • Apply live effects to images and text based in C++ code in a non destructive way: Slice, Mirror; Rotate, Perspective... even in groups with mixed elements types.

P9. Path Library Improvements

  • Estimation of difficulty: Hard
  • Potential mentors: Tavmjong Bah, KK
  • Programming skills: C++
  • Prerequisites: Strong math skills, specifically in geometry.

Detailed Description Inkscape relies on two geometry libraries for path manipulations: lib2geom and livarot. lib2geom is a generic modern library written specifically with Inkscape in mind. lib2geom is missing some functionality that Inkscape requires and that is found in livarot. This project is to move that functionality into lib2geom (or into separate files) using lib2geom path descriptions. Specifically, the functionality needed is

  • Path offset/inset functions.
  • Path simplify.
  • Stroke to path function.
  • Line scanning (used for flowing text into a shape).

P10. Your project

  • Estimation of difficulty: Variable
  • Potential mentors: Marc Jeanmougin
  • Programming skills: usually C++
  • Prerequisites: good ideas

Detailed Description The most successful GSoC we had in the past were students coming with their own past, use cases and ideas for Inkscape. Many basic tools like 3d cubes or connectors you can see in Inkscape now have been brought by brilliant people (like you) with ideas. If we think that your project fits with Inkscape (ie: has its place with a vector graphic editor), we can help you refining your ideas and help bring shiny new stuff to life!

Use cases

  • Amaze us!

Successful SOC Projects from Previous Years

  • 2005
  • 2006
    • Support for SVG Filters
    • Filter Effects
    • PDF export
    • Inkboard Protocol Spec / Lib Conversion
  • 2007
    • Text Style Improvements
    • PDF import
    • Live Path Effects
    • 3D Box Tool
    • UI for SVG Filter Effects
    • Raster Functionality
    • Importing from, and Exporting to, a remote ccHost instance
  • 2008
    • SVG Fonts support
    • 2Geom refactoring project - port most geometry code to 2Geom
    • lib2geom: interactive applications showing off the power of lib2geom
    • Tech drawing abilities
    • A test suite
  • 2009
  • 2010
    • Cairo-based rendering
    • C++ification of SP Layer
  • 2011
    • Rendering caching
    • Javascript support improvements
    • CSS support improvements
  • 2012
  • 2013
    • Recolor Tool
    • Improved Units Support
    • Electronics CAD Support
    • New From Templates Dialog
    • New Raster to Vector Algorithm
  • 2014
    • Better Support for SVG Paints
    • Robust Boolean and Stroking Operations for 2Geom
  • 2016
  • 2017
    • SVG 2 Text Support
    • Better CSS Style Sheet Support
Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=Google_Summer_of_Code&oldid=109036"