Difference between revisions of "Google Summer of Code 2007"

From Inkscape Wiki
Jump to navigation Jump to search
 
(19 intermediate revisions by 11 users not shown)
Line 1: Line 1:
This year Inkscape is going to participate, yet again, in Google's Summer of Code 2007. Help us come up with some solid places to innovate and push forward.
This year Inkscape is going to participate, yet again, in Google's Summer of Code (SoC) 2007. Help us come up with some solid places to innovate and push forward.


= Student Applications =
= Student Applications =


* Google program information
* Google program information
** GSoC Application form
** Summer of Code Application form
* Inkscape-specific information
* Inkscape-specific information
** [[SOC Application Template]]
** [[SOC Application Template]]
Line 13: Line 13:
= Project Ideas =
= Project Ideas =


== 3D capability ==
== General ==
 
=== 3D Tool ===


Inkscape is a 2D drawing tool. However, very often it is used to draw 3D objects. It would be very cool to have more support from the program for doing that, instead of just drawing everything manually. Nothing too fancy - we're not going to compete with Blender; but even simple things can go a long way. What's listed below is just basic ideas; feel free to develop upon them or offer something entirely different in your proposal.  
Inkscape is a 2D drawing tool. However, very often it is used to draw 3D objects. It would be very cool to have more support from the program for doing that, instead of just drawing everything manually. Nothing too fancy - we're not going to compete with Blender; but even simple things can go a long way. What's listed below is just basic ideas; feel free to develop upon them or offer something entirely different in your proposal.  


* A '''3D box tool''' would be able to:  
A '''3D box tool''' would be able to:  
 
*draw a 3D box;


:*draw a 3D box;  
*adjust any of its 3 dimensions by handles and numerically;  


:*adjust any of its 3 dimensions by handles and numerically;  
*freely move the perspective vanishing point for each dimension;  


:*freely move the perspective vanishing point for each dimension;  
*switch any dimension from a vanishing point to direction (point in infinity,  lines are parallel) and back;


:*switch any dimension from a vanishing point to direction (point in infinity,  lines are parallel) and back;
*subdivide or multiply the box to create perspective grids;


:*Allow subdivision of each face to create perspective grids;
*when more than one 3D box is selected and their perspective is compatible, drag their common vanishing points/directions updating all selected boxes;


:*when more than one 3D box is selected and their perspective is compatible, drag their common vanishing points/directions updating all selected boxes;
*3D-rotate the entire selected 3D box (or several selected 3D boxes if they have a compatible perspective), thus moving all 3 directions/vanishing points in a natural way;


:*3D-rotate the entire selected 3D box (or several selected 3D boxes if they have a compatible perspective), thus moving all 3 directions/vanishing points in a natural way;
*remember the last-set directions/vanishing points and create new objects in the same perspective, so you can quickly and easily draw an entire 3D scene with many boxes;


:*remember the last-set directions/vanishing points and create new objects in the same perspective, so you can quickly and easily draw an entire 3D scene with many boxes.
In SVG, a 3D box will be represented as a group (svg:g) with a special extension attribute (in inkscape namespace); the group would normally contain the 6 quadrilateral paths representing the sides of the box. Only the 3D box tool would treat this object as a whole; for all other tools it will be just a group, so you can select any of the paths, apply any style to it, delete it, etc. You can of course transform the group or any face in it using Selector or Node tools. At the same time, the 3D tool would still be able to 3D-rotate and 3D-tweak the box while preserving any changed style (but not necessarily preserving transforms or node edits of individual sides) and not restoring deleted sides (e.g. if you don't want to see the hidden sides, simply delete them as objects from the group). The tool must also be able to create "degenerate" boxes - planes and lines represented as boxes with one or two dimensions equal to zero.  


:In SVG, a 3D box will be represented as a group with a special extension attribute; the group would contain the 6 quadrilateral paths representing the sides of the box. Only the 3D box tool would treat this object as a whole; for all other tools it will be just a group, so you can select any of the paths, apply any style to it, delete it, etc. At the same time, the 3D tool would still be able to 3D-rotate and 3D-tweak the box while preserving any changed style and not restoring deleted sides (e.g. if you don't want to see the hidden sides, simply delete them as objects from the group).
In the UI, drawing with this tool creates a box with 4 handles on the box (3 for changing its dimensions and one in the center for dragging it in 3D) and 3 more perspective handles. If some dimension has a vanishing point, its perspective handle is (for example) diamond; if that dimension has infinity vanishing point, the corresponding handle is round (and can adjust only direction from the center). Dragging box handles without Shift moves them in X/Y plane, with Shift in Z. If multiple boxes selected and their perspectives are compatible, the corresponding handles snap together and dragging them affects everything selected.


* '''3D guides''' can be a helpful addition to the 3D box tool. You would be able to create a new set of 3D guides from any 3D box and then use these guides for drawing with any tool that can snap to guides (e.g. the Pen tool). The guides would use different colors  for the three dimensions. Ideally the guides should remember which object they were created from and update when that object's perspective (the set of 3 vanishing points or directions) is edited in the 3D tool.  
'''3D guides''' can be a helpful addition to the 3D box tool. You would be able to create a new set of 3D guides from any 3D box and then use these guides for drawing with any tool that can snap to guides (e.g. the Pen tool). The guides would use different colors  for the three dimensions. Ideally the guides should remember which object they were created from and update when that object's perspective (the set of 3 vanishing points or directions) is edited in the 3D tool.  


* '''Other primitives''': Sphere, Cylinder, Cone, Pyramid ...
'''Mini FAQ:'''


* '''Perspective transform tool''' like in the GIMP
*'''Why not improve integration with Blender instead?''' Because even if Inkscape/Blender integration were much more seamless than now, and even if Blender's UI were much more like Inkscape's, (neither of which is true), it would still suck to have a separate program for such a basic aspect of your drawing as (essentially) objects' shapes.


* '''Perspective grid tiling''': cloning an object to each field of a grid.
:Besides, Blender has a different approach to 3D than what I want for Inkscape. In Blender, you shape your objects, position them in a 3D space, and position your point of view in the same space to get some picture. That's fine if what you are interested in is the 3D world. But traditional artists do not work like that. They don't need a 3D world; they need a 2D drawing that gives an impression of 3D. From the times of Leonardo, this means starting with placing your perspective vanishing points/directions and then drawing objects to conform to these. That's the most natural approach for a 2D artist. I don't know if Blender allows you to freely drag the vanishing points at all (and even if it does, it's hardly the default editing mode in it). In Inkscape, that will be the main mode of interaction, very similar to the way all other shapes are edited by dragging their control handles.


This is a big and infinitely expandable area. We do not expect any single student to cover all of this in a single summer. You can propose a reasonably useful subset of this functionality as your 2007 GSoC project.
*'''Isn't it the same as Extrude or Perspective tools (e.g. in Corel Draw)?''' Not quite. Perspective distortion of an arbitrary path is something we very definitely need; extrude is also nice, especially for text headings. But they are both effects that, most often, just add a 3D eyecandy to existing objects. What I envision is a tool for a draftsman, a technical illustrator; something that lets you draw entire scenes in one common perspective easily. The main point of my proposal is, let's do the fundamentals right, before we do any eyecandy. And in the world of 3D, a basic '''3D box''' is as fundamental as you can get. '''Everything else stems from it or can be defined by it;''' this tool can be used as a generic "definer" of the perspective. For example, you can:


<b>Mentor:</b>  bbyak
:* take one 3D box, copy its perspective, and paste on other boxes;


== Native EPS and/or PDF Import ==
:* project a path onto a side of the box ("perspective envelope");


While SVG is becoming a common format for exchanging data between graphics programs, EPS and PDF are still much more common.  Inkscape's current EPS import is flakey, based on 3rd party software, and poorly maintained.  The goal is to give Inkscape native EPS and/or PDF import capability.
:* apply the box's perspective and bounds to any object to extrude it;


Where the code can be borrowed from:  
:*tell it to inscribe other 3D primitives (cylinder, cone, pyramid) into a box;


*For EPS: Scribus' EPS Import Library
:* do "perspective clone tiling": cloning an object to each cell of a 3D grid defined by a box;


*For PDF: poppler library
:* even enable ellipse and other drawing tools to draw in one plane of the currently selected box's perspective.


*For both: Ghostscript (though it may be too heavy for us)


The student needs to evaluate these (or other) possibilities, lay out a plan, and implement a native importer in Inkscape, either using an external lib to link to, or just importing the necessary code directly into Inkscape tree (as we did for Potrace). The end result will be Inkscape being able to correctly import a reasonable majority of EPS and/or PDF files in the wild (we can agree on a more formal conformance test if this idea interests anyone).
This is a big and infinitely expandable area. We do not expect any single student to cover all of this in a single summer. You can propose a reasonably useful subset of this functionality as your 2007 GSoC project.


<b>Mentor:</b>  ???
<b>Mentor:</b>  Bulia Byak


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


As explained on [[LivePathEffects|this wiki page]], Live Path Effects allow arbitrary path-changing effects to be applied to any path object. Inkscape will remember the original path before the transformation was applied, so you will be able to remove the effect, chain several effects on the same path, adjust their parameters, etc. All the effects metadata will be stored in Inkscape-only attributes. At the same time, the resulting visible path (with the effects applied) is saved using pure SVG elements and attributes and thus visible to all SVG renderers, thus upholding Inkscape's basic principle of operation: drawings must look exactly the same in Inkscape as in any SVG-compliant renderer.
As explained on [[LivePathEffects|this wiki page]], Live Path Effects allow arbitrary path-changing effects to be applied to any path object. Inkscape will remember the original path before the transformation was applied, so you will be able to remove the effect, chain several effects on the same path, adjust their parameters, etc. All the effects metadata will be stored in Inkscape-only attributes. At the same time, the resulting visible path (with the effects applied) is saved using pure SVG elements and attributes and thus visible to all SVG renderers, thus upholding Inkscape's basic principle of operation: drawings must look exactly the same in Inkscape as in any SVG-compliant renderer.
Line 71: Line 74:
This approach will allow us to make many of the effects currently implemeted as extensions (in the Effects menu) live and interactive. Path randomization, putting pattern along path, blends, envelopes, various distortions - all these can and should be live path effects, not the clunky, slow, and inconvenient Python scripts. Fortunately, Inkscape architecture makes creating live path effects relatively easy.
This approach will allow us to make many of the effects currently implemeted as extensions (in the Effects menu) live and interactive. Path randomization, putting pattern along path, blends, envelopes, various distortions - all these can and should be live path effects, not the clunky, slow, and inconvenient Python scripts. Fortunately, Inkscape architecture makes creating live path effects relatively easy.


To complete this project, a student must implement at least several simple effects, propose and create a basic UI for applying them to paths (Path Effects tool?). Some of the effects that you could start with are:
To complete this project, a student must implement at least several simple effects, propose and create a basic user interface for applying them to paths (Path Effects tool?). Some of the effects that you could start with are:
 
* '''Patterned or "skeletal" strokes''': Similar to the "Pattern along path" extension in 0.45, but fully interactive and auto-updating. You can edit the "skeleton" path and the pattern applied to it at any time.


* '''Filleting''' (corner rounding) is common in technical drawing.  While this is a fairly basic drafting task, it's currently not particularly easy to do in Inkscape except for certain cases such as round cornered rectangles.  This effect would apply rounding with a given radius to all or some sharp corners of a path. It should also permit creation of '''chamfers''' which are flattened edges at suitable angles.
* '''Filleting''' (corner rounding) is common in technical drawing.  While this is a fairly basic drafting task, it's currently not particularly easy to do in Inkscape except for certain cases such as round cornered rectangles.  This effect would apply rounding with a given radius to all or some sharp corners of a path. It should also permit creation of '''chamfers''' which are flattened edges at suitable angles.
Line 79: Line 84:
<b>Mentor:</b>  Aaron Spike
<b>Mentor:</b>  Aaron Spike


== Native CDR (Corel Draw) import/export ==
=== Inkboard Portability ===
 
In some parts of the world, Corel Draw was (and probably is) more popular than Adobe Illustrator. Tons of graphics and clipart exist in this format. Corel's UI is similar to Inkscape's and Xara's (and quite different from that of AI), which makes Inkscape more attractive for Corel Draw artists. We are getting a lot of requests from users to support this format.
 
While CDR is not an open format, several open source implementations exist, from which you can borrow code:
 
* Open source [http://xaralx.org/ Xara LX] can import and export CDR files.
 
* [http://sk1.sourceforge.net sK1] is a Corel Draw lookalike vector editor, at early stages of development but claiming to be able to read CDR files.
 
* CDR files use [http://en.wikipedia.org/wiki/RIFF RIFF metaformat], which means you can easily find an open source library for reading the top layer of the format (try any open source app that can read WAV or AVI, which are also RIFF-based).
 
A student for this project will need to plan the scope of the feature (we do not need to do all the fancy features, but basics need to be covered) and assemble, with the help of the mentor, a library of sample CDR files for testing.
 
'''Mentor:''' bbyak
 
== Inkboard Portability ==


Last year we had a successful project to integrate the SVG online whiteboard capability, called Inkboard, into Inkscape.  Unfortunately, it does not work on Windows, so many users are missing out on this capability.
Last year we had a successful project to integrate the SVG online whiteboard capability, called Inkboard, into Inkscape.  Unfortunately, it does not work on Windows, so many users are missing out on this capability.
Line 103: Line 92:
<b>Mentor:</b>  Ted
<b>Mentor:</b>  Ted


== New Grids ==
=== New Grids ===


Inkscape currently has square grids that can be snapped to.  Extend this to allow other kinds of grids:  Perspective, hex, iso, etc.
Inkscape currently has square grids that can be snapped to.  Extend this to allow other kinds of grids:  Perspective, hex, iso, etc.
Line 119: Line 108:




=== Text Tool Improvements ===
Inkscape's text tool is handy, but still lacks many of the niceties that users would like.  This project would seek to address this by implementing various improvements that users have requested.
Some ideas for improvements:
* When flowing a text which already contains line breaks, provide a way for the line breaks to be conserved
* When the style selected in the the Text and Font dialog is applied it erases any other style applied to some part of the text (like italics on some words, bold on others&hellip;), it would also be better to keep them where appropriate.
* Support [http://www.w3.org/TR/SVG11/text.html#TextDecorationProperties text-decoration] (underline, overline, line-through)
* Better respect different faces of fonts (Light, Book, Normal, Black etc.)
* Support justified text - might be some subset of those proposed at http://www.w3.org/TR/css3-text/; see also http://bowman.csse.monash.edu.au/~pmoulder/text-in-shape.tar.gz as a possible starting point.
* Paragraph styling - space before &amp; after paragraphs, indent left &amp; right.
* Spellchecking.  Inkscape includes limited spellchecking support based on aspell but it is not enabled by default.  Spellchecking based on enchant could use a much wider range of spellchecking engines and be made more widely available and be good enough to show prominently and enable by default. 
* Search through the Inkscape Request for Enhancement (RFE) list for other text and font improvement ideas. 
See also: http://valessio.ul-jb.org/projetos/inkscape/inkscribus.htm
<b>Mentor:</b> TBD
=== Color Adjustment Dialog ===
Currently, it is possible to select, say, 12 objects in the drawing and set them to the same color/gradient/pattern.  This project would go a step further, allowing multiple objects of differing color to have aspects of their color (such as brightness/contrast, HSL, etc.) altered, and to operate on vector objects with different fill styles (flat, gradient, or pattern fills), and to bitmaps.
Note: in 0.45, we have a set of extension effects that do this. But they are clumsy and slow. We need this to be in the core of the program with a good interactive user interface.
<b>Mentor:</b>  Bulia Byak
== Import/export ==
=== Native Import of Encapsulated Poscript (EPS) or Adobe Portable Document Format (PDF) ===
While SVG is becoming a common format for exchanging data between graphics programs, EPS and PDF are still much more common.  Inkscape's current EPS import is brittle, not as well maitained as we might like, and not available for all target platforms as it depends on 3rd party software.  The goal is to give Inkscape native EPS or PDF import capability.
Where the code can be borrowed from:
*For EPS: Scribus' EPS Import Library
*For PDF: Poppler library  http://poppler.freedesktop.org/
*For both: Ghostscript (though it may be too heavy for us)
The student needs to evaluate these (or other) possibilities, lay out a plan, and implement a native importer in Inkscape, either using an external lib to link to, or just importing the necessary code directly into Inkscape tree (as we did for Potrace). The end result will be Inkscape being able to correctly import a reasonable majority of EPS or PDF files in the wild (we can agree on a more formal conformance test if this idea interests anyone).
<b>Mentor:</b>  ???
=== Native Import/Export of Corel Draw (CDR) files ===
Corel Draw was and still is a very popular drawing application and many files exist in the Corel Draw format.  The user interface of Corel Draw is more similar in many ways to Inkscape than other graphics software making Inkscape more attractive to Corel Draw artists.  We are getting a lot of requests from users to support this format. 
While CDR is not an open format, several open source implementations exist, from which you can borrow code:
* Open source [http://xaralx.org/ Xara LX] can import and export CDR files.
* [http://sk1.sourceforge.net sK1] is a Corel Draw lookalike vector editor, at early stages of development but claiming to be able to read CDR files.
* CDR files use [http://en.wikipedia.org/wiki/RIFF RIFF metaformat], which means you can easily find an open source library for reading the top layer of the format (try any open source app that can read WAV or AVI, which are also RIFF-based).  http://en.wikipedia.org/wiki/.cdr
A student for this project will need to plan the scope of the feature (we do not need to do all the fancy features, but basics need to be covered) and assemble, with the help of the mentor, a library of sample CDR files for testing.
'''Mentor:''' Bulia Byak
=== ccHost Import/Export ===


== SVG Filters UI ==
Allow exporting to, or importing from, a remote ccHost instance.


Filters are a very important [http://www.w3.org/TR/SVG/filters.html SVG capability].
In particular, export to the [http://www.openclipart.org/ Open Clip Art Library (OCAL)], and import from said library (with some search terms, tag words, and perhaps even browsing.)
 
[[LionKimbro]] can help someone spec out the capabilities, interfaces (both programmatic and GUI), and so on.  He's written a little on [[Open Clip Art Library Integration]] already.  cell: 206.427.2545.
 
== SVG features ==
 
=== SVG Font support ===
 
We need SVG Font support in order to be able to claim SVG Tiny support. While the occurrence of SVG fonts in the wild seems to be pretty low, we will benefit from this by being able to embed fonts and thus ensure rendering of text without converting it to paths.
 
<b>Mentor:</b>  ???
 
=== External Cascading Stylesheet (CSS) Support ===
 
Inkscape currently has good support for inline CSS, and limited read-only support for an internal stylesheet in a <style> element, and no support for external stylesheets. Support for editing non-inline CSS would allow better expressiveness and adaptation, and smaller SVG files, and better support for SVG generated by other programs that use non-inline CSS.


Inkscape has basic support for filters in general thanks to a couple GSoC students' work last year, and more or less complete support for Gaussian Blur. What is needed: (1) adding support for more filters and making sure they work well in combination; (2) designing a UI that will be able to create, view, and modify arbitrarily complex filter stacks.
<b>Mentor:</b> Peter Moulder


<b>Mentor:</b> Bulia
=== Multi-page Support ===


== Adding bitmap capabilities to Inkscape ==
An often requested feature is for Inkscape to support multi-page editing. 
Currently, an Inkscape document is set to correspond to 1 printed page.  However, the next version of SVG specification (1.2) includes support for [http://jan.kollhof.net/projects/svg/motjuvie/present.xhtml multi-page documents], and lots of people would like to have this capability in Inkscape as well.


While the purpose of Inkscape is to be a vector editor, design in the real world requires dealing with bitmaps too. Inkscape can import the bitmaps, and have them as full canvas objects, but there is no significant bitmap operations in Inkscape. While there is no reason for Inkscape to replicate the functionality of The GIMP, it would be desirable to have a few simple operations available from Inkscape.
This project would involve several steps:  1)  Add internal support for reading and writing SVG 1.2 <pageSet> and <page> elements.  2) When editing a pageSet, create the visual page frames for each <page>. 3) When exporting to Postscript, have it export each <page> as a separate page in the Postscript file.


This project will use the Inkscape extensions system to add a series of bitmap effects. The majority of the effects will be achieved through the integration of the ImageMagick bitmap handling libraries.  GIMP may be another source.  These effects can then be run on bitmap graphics within Inkscape.
(Another frequent request is support for a tabbed interface. To be clear a tabbed interface is quite a different request from this one and any such Tabbed interface would need to accomodate the requirement of single documents with multiple pages like those proposed in SVG and already existing in PDF, OpenDocument Draw, and many others.)


The work should be encapsulated in such a way that in theory, other vector graphics applications (such as Xara), could also use the work.  However, for the scope of this project we only require demonstration of the capabilities in Inkscape.
=== User Interface for SVG Filters ===


Filters are a very important [http://www.w3.org/TR/SVG/filters.html SVG capability].


<b>Project Timeline:</b>
Inkscape has basic support for filters in general thanks to a couple GSoC students' work last year, and more or less complete support for Gaussian Blur. What is needed: (1) adding support for more filters and making sure they work well in combination; (2) designing a UI that will be able to create, view, and modify arbitrarily complex filter stacks.


* Implement first effect. This involves building Inkscape, linking in ImageMagick and getting one effect written (6 weeks)
<b>Mentor:</b> Bulia Byak
* Implement remaining effects within ImageMagick (3 weeks)
* Build a test suite for operations and complete all Doxygen documentation of code (3 weeks)


<b>Mentor:</b>  Ted




== Raster Graphics ==


== Inkscape / GIMP Bitmap Editing Integration ==
=== Inkscape / GIMP raster graphics Editing Integration ===


Currently, you can embed raster/bitmap images into Inkscape drawings, but editing them is a bit of a hassle because Inkscape isn't really "aware" of external bitmap editing tools.
Currently, you can embed raster/bitmap images into Inkscape drawings, but editing them is a bit of a hassle because Inkscape isn't really "aware" of external bitmap editing tools.
Line 159: Line 224:
<b>Mentor:</b>  TBD
<b>Mentor:</b>  TBD


== Text Tool Improvements ==
=== Adding raster capabilities to Inkscape ===


Inkscape's text tool is handy, but still lacks many of the niceties that users would like.  This project would seek to address this by implementing various improvements that users have requested.
While the purpose of Inkscape is to be a vector editor, design in the real world requires dealing with bitmaps too. Inkscape can import the bitmaps, and have them as full canvas objects, but there is no significant bitmap operations in Inkscape. While there is no reason for Inkscape to replicate the functionality of The GIMP, it would be desirable to have a few simple operations available from Inkscape.


Some ideas for improvements:
This project will use the Inkscape extensions system to add a series of bitmap effects. The majority of the effects will be achieved through the integration of the ImageMagick bitmap handling libraries. GIMP may be another source. These effects can then be run on bitmap graphics within Inkscape.
* Make flowed text respect the default style of the text tool (a simple bugfix)
* When flowing a text which already contains line breaks, provide a way for the line breaks to be conserved
* When the style selected in the the Text and Font dialog is applied it erases any other style applied to some part of the text (like italics on some words, bold on others...), it would also be better to keep them where appropriate.
* Support [http://www.w3.org/TR/SVG11/text.html#TextDecorationProperties text-decoration] (underline, overline, line-through)
* Better respect different faces of fonts (Light, Book, Normal, Black etc.)
* Support justified text - might be some subset of those proposed at http://www.w3.org/TR/css3-text/; see also http://bowman.csse.monash.edu.au/~pmoulder/text-in-shape.tar.gz as a possible starting point.
* Search through the Inkscape RFE list for other text and font improvement ideas


See also: http://valessio.ul-jb.org/projetos/inkscape/inkscribus.htm
The work should be encapsulated in such a way that in theory, other vector graphics applications (such as Xara), could also use the work. However, for the scope of this project we only require demonstration of the capabilities in Inkscape.


<b>Mentor:</b> TBD
There are various requests in the tracker on this topic but they are difficult to identify since a mix of terminology is used, such as bitmap, raster, pixel and other graphics terms.  Ask the developers on the mailing lists if in doubt.


<b>Project Timeline:</b>


== Color Adjustment Dialog ==
* Implement first effect. This involves building Inkscape, linking in ImageMagick and getting one effect written (6 weeks)
* Implement remaining effects within ImageMagick (3 weeks)
* Build a test suite for operations and complete all Doxygen documentation of code (3 weeks)


Currently, it is possible to select, say, 12 objects in the drawing and set them to the same color/gradient/pattern. This project would go a step further, allowing multiple objects of differing color to have aspects of their color (such as brightness/contrast, HSL, etc.) altered, and to operate on vector objects with different fill styles (flat, gradient, or pattern fills), and to bitmaps.
<b>Mentor:</b> Ted Gould


Note: in 0.45, we have a set of extension effects that do this. But they are clumsy and slow. We need this to be in the core of the program with a good interactive UI.


<b>Mentor:</b>  Bulia






== SVG fonts support ==
== Your own original ideas ==  


We need SVG font support in order to be able to claim SVG Tiny support. While the occurrence of SVG fonts in the wild seems to be pretty low, we will benefit from this by being able to embed fonts and thus ensure rendering of text without converting it to paths.  
Original ideas are also welcome but students stand a better chance of getting selected by choosing from the suggested projects and where a mentor is available to supervise the work. If in doubt contact the developers on the mailing lists.


<b>Mentor:</b>  ???


= Accepted by Google =


*[http://www.scs.carleton.ca/~gbanaszk/code/soc07/index.htm Text Improvements]
** by Gail Banaszkiewicz, mentored by Richard Hughes


== External CSS Support ==
* Native PDF import capability based on libpoppler 
**by Miklos Erdelyi, mentored by Jon Cruz


Inkscape currently has good support for inline CSS, and limited read-only support for an internal stylesheet in a <style> element, and no support for external stylesheets.  Support for editing non-inline CSS would allow better expressiveness and adaptation, and smaller SVG files, and better support for SVG generated by other programs that use non-inline CSS.
* [[GSOC2007 Live path effects in Inkscape|Live path effects in Inkscape]]
** by Johan Engelen, mentored by Aaron Spike


<b>Mentor:</b> Peter Moulder
* [[GSOC2007 3D box tool|3D box tool for Inkscape]]
** by Maximilian Albert, mentored by bulia byak


== Multi-page Support ==
* UI for SVG Filter Effects
** by Nicholas Bishop, mentored by MenTaLguY


An oft-requested feature is for Inkscape to support multi-page editing.  Currently, an Inkscape document is set to correspond to 1 printed page.  However, the next version of SVG specification (1.2) includes support for [http://jan.kollhof.net/projects/svg/motjuvie/present.xhtml multi-page documents], and lots of people would like to have this capability in Inkscape as well.
* Raster Functionality in Inkscape
** by Christopher Brown, mentored by Theodore J. Gould


This project would involve several steps:  1)  Add internal support for reading and writing SVG 1.2 <pageSet> and <page> elements.  2) When editing a pageSet, create the visual page frames for each <page>. 3) When exporting to Postscript, have it export each <page> as a separate page in the Postscript file.
* Importing from, and Exporting to, a remote ccHost instance  
**by Bruno Lu Gon-alves Dilly, mentored by Bryce Harrington


= Past Years =
= Past Years =


* [[Googles Summer of Code 2006]]
* [[Google Summer of Code 2006]]
* Googles Summer of Code 2005
* [[Google Summer of Code 2005]]
** [[SOC Accepted Proposals]]
** [[SOC Accepted Proposals]]
** [[SOC Writing Project Proposals]]
** [[SOC Writing Project Proposals]]
** [[SOC Selection Criteria]]
** [[SOC Selection Criteria]]
** [[SOC Original Project Prompts]]
** [[SOC Original Project Prompts]]

Latest revision as of 13:25, 12 February 2012

This year Inkscape is going to participate, yet again, in Google's Summer of Code (SoC) 2007. Help us come up with some solid places to innovate and push forward.

Student Applications

Project Ideas

General

3D Tool

Inkscape is a 2D drawing tool. However, very often it is used to draw 3D objects. It would be very cool to have more support from the program for doing that, instead of just drawing everything manually. Nothing too fancy - we're not going to compete with Blender; but even simple things can go a long way. What's listed below is just basic ideas; feel free to develop upon them or offer something entirely different in your proposal.

A 3D box tool would be able to:

  • draw a 3D box;
  • adjust any of its 3 dimensions by handles and numerically;
  • freely move the perspective vanishing point for each dimension;
  • switch any dimension from a vanishing point to direction (point in infinity, lines are parallel) and back;
  • subdivide or multiply the box to create perspective grids;
  • when more than one 3D box is selected and their perspective is compatible, drag their common vanishing points/directions updating all selected boxes;
  • 3D-rotate the entire selected 3D box (or several selected 3D boxes if they have a compatible perspective), thus moving all 3 directions/vanishing points in a natural way;
  • remember the last-set directions/vanishing points and create new objects in the same perspective, so you can quickly and easily draw an entire 3D scene with many boxes;

In SVG, a 3D box will be represented as a group (svg:g) with a special extension attribute (in inkscape namespace); the group would normally contain the 6 quadrilateral paths representing the sides of the box. Only the 3D box tool would treat this object as a whole; for all other tools it will be just a group, so you can select any of the paths, apply any style to it, delete it, etc. You can of course transform the group or any face in it using Selector or Node tools. At the same time, the 3D tool would still be able to 3D-rotate and 3D-tweak the box while preserving any changed style (but not necessarily preserving transforms or node edits of individual sides) and not restoring deleted sides (e.g. if you don't want to see the hidden sides, simply delete them as objects from the group). The tool must also be able to create "degenerate" boxes - planes and lines represented as boxes with one or two dimensions equal to zero.

In the UI, drawing with this tool creates a box with 4 handles on the box (3 for changing its dimensions and one in the center for dragging it in 3D) and 3 more perspective handles. If some dimension has a vanishing point, its perspective handle is (for example) diamond; if that dimension has infinity vanishing point, the corresponding handle is round (and can adjust only direction from the center). Dragging box handles without Shift moves them in X/Y plane, with Shift in Z. If multiple boxes selected and their perspectives are compatible, the corresponding handles snap together and dragging them affects everything selected.

3D guides can be a helpful addition to the 3D box tool. You would be able to create a new set of 3D guides from any 3D box and then use these guides for drawing with any tool that can snap to guides (e.g. the Pen tool). The guides would use different colors for the three dimensions. Ideally the guides should remember which object they were created from and update when that object's perspective (the set of 3 vanishing points or directions) is edited in the 3D tool.

Mini FAQ:

  • Why not improve integration with Blender instead? Because even if Inkscape/Blender integration were much more seamless than now, and even if Blender's UI were much more like Inkscape's, (neither of which is true), it would still suck to have a separate program for such a basic aspect of your drawing as (essentially) objects' shapes.
Besides, Blender has a different approach to 3D than what I want for Inkscape. In Blender, you shape your objects, position them in a 3D space, and position your point of view in the same space to get some picture. That's fine if what you are interested in is the 3D world. But traditional artists do not work like that. They don't need a 3D world; they need a 2D drawing that gives an impression of 3D. From the times of Leonardo, this means starting with placing your perspective vanishing points/directions and then drawing objects to conform to these. That's the most natural approach for a 2D artist. I don't know if Blender allows you to freely drag the vanishing points at all (and even if it does, it's hardly the default editing mode in it). In Inkscape, that will be the main mode of interaction, very similar to the way all other shapes are edited by dragging their control handles.
  • Isn't it the same as Extrude or Perspective tools (e.g. in Corel Draw)? Not quite. Perspective distortion of an arbitrary path is something we very definitely need; extrude is also nice, especially for text headings. But they are both effects that, most often, just add a 3D eyecandy to existing objects. What I envision is a tool for a draftsman, a technical illustrator; something that lets you draw entire scenes in one common perspective easily. The main point of my proposal is, let's do the fundamentals right, before we do any eyecandy. And in the world of 3D, a basic 3D box is as fundamental as you can get. Everything else stems from it or can be defined by it; this tool can be used as a generic "definer" of the perspective. For example, you can:
  • take one 3D box, copy its perspective, and paste on other boxes;
  • project a path onto a side of the box ("perspective envelope");
  • apply the box's perspective and bounds to any object to extrude it;
  • tell it to inscribe other 3D primitives (cylinder, cone, pyramid) into a box;
  • do "perspective clone tiling": cloning an object to each cell of a 3D grid defined by a box;
  • even enable ellipse and other drawing tools to draw in one plane of the currently selected box's perspective.


This is a big and infinitely expandable area. We do not expect any single student to cover all of this in a single summer. You can propose a reasonably useful subset of this functionality as your 2007 GSoC project.

Mentor: Bulia Byak

Live Path Effects

As explained on this wiki page, Live Path Effects allow arbitrary path-changing effects to be applied to any path object. Inkscape will remember the original path before the transformation was applied, so you will be able to remove the effect, chain several effects on the same path, adjust their parameters, etc. All the effects metadata will be stored in Inkscape-only attributes. At the same time, the resulting visible path (with the effects applied) is saved using pure SVG elements and attributes and thus visible to all SVG renderers, thus upholding Inkscape's basic principle of operation: drawings must look exactly the same in Inkscape as in any SVG-compliant renderer.

This approach will allow us to make many of the effects currently implemeted as extensions (in the Effects menu) live and interactive. Path randomization, putting pattern along path, blends, envelopes, various distortions - all these can and should be live path effects, not the clunky, slow, and inconvenient Python scripts. Fortunately, Inkscape architecture makes creating live path effects relatively easy.

To complete this project, a student must implement at least several simple effects, propose and create a basic user interface for applying them to paths (Path Effects tool?). Some of the effects that you could start with are:

  • Patterned or "skeletal" strokes: Similar to the "Pattern along path" extension in 0.45, but fully interactive and auto-updating. You can edit the "skeleton" path and the pattern applied to it at any time.
  • Filleting (corner rounding) is common in technical drawing. While this is a fairly basic drafting task, it's currently not particularly easy to do in Inkscape except for certain cases such as round cornered rectangles. This effect would apply rounding with a given radius to all or some sharp corners of a path. It should also permit creation of chamfers which are flattened edges at suitable angles.
  • Fractalize is currently a Python effect but would make a great live path effect. It can be useful in mapmaking; maps involve lots of irregular shapes - coastlines, forest boundaries, rivers, etc. that could use fractalization with adjustable level. (As an added bonus, this could be implemented so that the level of fractalization depends on zoom, but preserving this behavior outside of Inkscape would require some smart scripting as explained in this paper: Adaptive Level of Detail in SVG.)

Mentor: Aaron Spike

Inkboard Portability

Last year we had a successful project to integrate the SVG online whiteboard capability, called Inkboard, into Inkscape. Unfortunately, it does not work on Windows, so many users are missing out on this capability.

This work may involve formalizing and extending the Inkboard communication protocol and working on the INKBOARD_PEDRO branch)

Mentor: Ted

New Grids

Inkscape currently has square grids that can be snapped to. Extend this to allow other kinds of grids: Perspective, hex, iso, etc.

This will involve modifying the grid code to support the ability to have multiple kinds of grids, implementing at least 3 new grids, and adding the UI elements to allow users to make use of them.

Requests in tracker:

Mentor: TBD


Text Tool Improvements

Inkscape's text tool is handy, but still lacks many of the niceties that users would like. This project would seek to address this by implementing various improvements that users have requested.

Some ideas for improvements:

  • When flowing a text which already contains line breaks, provide a way for the line breaks to be conserved
  • When the style selected in the the Text and Font dialog is applied it erases any other style applied to some part of the text (like italics on some words, bold on others…), it would also be better to keep them where appropriate.
  • Support text-decoration (underline, overline, line-through)
  • Better respect different faces of fonts (Light, Book, Normal, Black etc.)
  • Support justified text - might be some subset of those proposed at http://www.w3.org/TR/css3-text/; see also http://bowman.csse.monash.edu.au/~pmoulder/text-in-shape.tar.gz as a possible starting point.
  • Paragraph styling - space before & after paragraphs, indent left & right.
  • Spellchecking. Inkscape includes limited spellchecking support based on aspell but it is not enabled by default. Spellchecking based on enchant could use a much wider range of spellchecking engines and be made more widely available and be good enough to show prominently and enable by default.
  • Search through the Inkscape Request for Enhancement (RFE) list for other text and font improvement ideas.

See also: http://valessio.ul-jb.org/projetos/inkscape/inkscribus.htm

Mentor: TBD

Color Adjustment Dialog

Currently, it is possible to select, say, 12 objects in the drawing and set them to the same color/gradient/pattern. This project would go a step further, allowing multiple objects of differing color to have aspects of their color (such as brightness/contrast, HSL, etc.) altered, and to operate on vector objects with different fill styles (flat, gradient, or pattern fills), and to bitmaps.

Note: in 0.45, we have a set of extension effects that do this. But they are clumsy and slow. We need this to be in the core of the program with a good interactive user interface.

Mentor: Bulia Byak


Import/export

Native Import of Encapsulated Poscript (EPS) or Adobe Portable Document Format (PDF)

While SVG is becoming a common format for exchanging data between graphics programs, EPS and PDF are still much more common. Inkscape's current EPS import is brittle, not as well maitained as we might like, and not available for all target platforms as it depends on 3rd party software. The goal is to give Inkscape native EPS or PDF import capability.

Where the code can be borrowed from:

  • For EPS: Scribus' EPS Import Library
  • For both: Ghostscript (though it may be too heavy for us)

The student needs to evaluate these (or other) possibilities, lay out a plan, and implement a native importer in Inkscape, either using an external lib to link to, or just importing the necessary code directly into Inkscape tree (as we did for Potrace). The end result will be Inkscape being able to correctly import a reasonable majority of EPS or PDF files in the wild (we can agree on a more formal conformance test if this idea interests anyone).

Mentor:  ???

Native Import/Export of Corel Draw (CDR) files

Corel Draw was and still is a very popular drawing application and many files exist in the Corel Draw format. The user interface of Corel Draw is more similar in many ways to Inkscape than other graphics software making Inkscape more attractive to Corel Draw artists. We are getting a lot of requests from users to support this format.

While CDR is not an open format, several open source implementations exist, from which you can borrow code:

  • Open source Xara LX can import and export CDR files.
  • sK1 is a Corel Draw lookalike vector editor, at early stages of development but claiming to be able to read CDR files.

A student for this project will need to plan the scope of the feature (we do not need to do all the fancy features, but basics need to be covered) and assemble, with the help of the mentor, a library of sample CDR files for testing.

Mentor: Bulia Byak

ccHost Import/Export

Allow exporting to, or importing from, a remote ccHost instance.

In particular, export to the Open Clip Art Library (OCAL), and import from said library (with some search terms, tag words, and perhaps even browsing.)

LionKimbro can help someone spec out the capabilities, interfaces (both programmatic and GUI), and so on. He's written a little on Open Clip Art Library Integration already. cell: 206.427.2545.

SVG features

SVG Font support

We need SVG Font support in order to be able to claim SVG Tiny support. While the occurrence of SVG fonts in the wild seems to be pretty low, we will benefit from this by being able to embed fonts and thus ensure rendering of text without converting it to paths.

Mentor:  ???

External Cascading Stylesheet (CSS) Support

Inkscape currently has good support for inline CSS, and limited read-only support for an internal stylesheet in a <style> element, and no support for external stylesheets. Support for editing non-inline CSS would allow better expressiveness and adaptation, and smaller SVG files, and better support for SVG generated by other programs that use non-inline CSS.

Mentor: Peter Moulder

Multi-page Support

An often requested feature is for Inkscape to support multi-page editing. Currently, an Inkscape document is set to correspond to 1 printed page. However, the next version of SVG specification (1.2) includes support for multi-page documents, and lots of people would like to have this capability in Inkscape as well.

This project would involve several steps: 1) Add internal support for reading and writing SVG 1.2 <pageSet> and <page> elements. 2) When editing a pageSet, create the visual page frames for each <page>. 3) When exporting to Postscript, have it export each <page> as a separate page in the Postscript file.

(Another frequent request is support for a tabbed interface. To be clear a tabbed interface is quite a different request from this one and any such Tabbed interface would need to accomodate the requirement of single documents with multiple pages like those proposed in SVG and already existing in PDF, OpenDocument Draw, and many others.)

User Interface for SVG Filters

Filters are a very important SVG capability.

Inkscape has basic support for filters in general thanks to a couple GSoC students' work last year, and more or less complete support for Gaussian Blur. What is needed: (1) adding support for more filters and making sure they work well in combination; (2) designing a UI that will be able to create, view, and modify arbitrarily complex filter stacks.

Mentor: Bulia Byak


Raster Graphics

Inkscape / GIMP raster graphics Editing Integration

Currently, you can embed raster/bitmap images into Inkscape drawings, but editing them is a bit of a hassle because Inkscape isn't really "aware" of external bitmap editing tools.

This project would seek to correct this by modifying inkscape's image embedding code to interoperate more directly with external bitmap programs. For instance, there would be an "open external editor" command that could be used when one or more bitmap images are selected. Another idea would be to include some common bitmap modification commands from the external program, that can be run entirely within Inkscape. A third idea is drag and drop of selections from the bitmap editor to Inkscape, and SVG selections from Inkscape to the bitmap tool.

As a proof of concept, the result should demonstrate this interoperability with GIMP and/or GeGL. Note that the code should be developed such that in theory it should work with any bitmap editor, but we would only require demonstration of working with GIMP.

Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=862655&group_id=93438&atid=604309

Mentor: TBD

Adding raster capabilities to Inkscape

While the purpose of Inkscape is to be a vector editor, design in the real world requires dealing with bitmaps too. Inkscape can import the bitmaps, and have them as full canvas objects, but there is no significant bitmap operations in Inkscape. While there is no reason for Inkscape to replicate the functionality of The GIMP, it would be desirable to have a few simple operations available from Inkscape.

This project will use the Inkscape extensions system to add a series of bitmap effects. The majority of the effects will be achieved through the integration of the ImageMagick bitmap handling libraries. GIMP may be another source. These effects can then be run on bitmap graphics within Inkscape.

The work should be encapsulated in such a way that in theory, other vector graphics applications (such as Xara), could also use the work. However, for the scope of this project we only require demonstration of the capabilities in Inkscape.

There are various requests in the tracker on this topic but they are difficult to identify since a mix of terminology is used, such as bitmap, raster, pixel and other graphics terms. Ask the developers on the mailing lists if in doubt.

Project Timeline:

  • Implement first effect. This involves building Inkscape, linking in ImageMagick and getting one effect written (6 weeks)
  • Implement remaining effects within ImageMagick (3 weeks)
  • Build a test suite for operations and complete all Doxygen documentation of code (3 weeks)

Mentor: Ted Gould



Your own original ideas

Original ideas are also welcome but students stand a better chance of getting selected by choosing from the suggested projects and where a mentor is available to supervise the work. If in doubt contact the developers on the mailing lists.


Accepted by Google

  • Native PDF import capability based on libpoppler
    • by Miklos Erdelyi, mentored by Jon Cruz
  • UI for SVG Filter Effects
    • by Nicholas Bishop, mentored by MenTaLguY
  • Raster Functionality in Inkscape
    • by Christopher Brown, mentored by Theodore J. Gould
  • Importing from, and Exporting to, a remote ccHost instance
    • by Bruno Lu Gon-alves Dilly, mentored by Bryce Harrington

Past Years