Google Summer of Code 2006

From Inkscape Wiki
Revision as of 19:42, 30 April 2006 by BryceHarrington (talk | contribs)
Jump to navigation Jump to search

SOC 2006

Google has been kind enough to invite Inkscape to participate as a mentoring organization in the Summer of Code 2006. The students and developers had a lot of fun last year, and resulted in some _great_ additions to the software, so we are very enthused about this year.

Below is a list of ideas that Inkscape developers think might make good projects. Please do not let this list constrain you; if you have a good idea beyond what is listed we'd love to see it!

Also, we would strongly encourage students to contact us on the Inkscape developer's list prior to submitting your proposal. This gives us a chance to get to know you and to give you feedback that will strengthen your proposal.

Project Ideas

A. CSS Support

Inkscape currently supports inline CSS, but real support for non-inline CSS would allow storing style elements in the document head or an external file, and help prevent a lot of duplication of style info inline. It will also improve the ability to use SVG generated by other programs that use non-inline CSS.

Mentor: TBD

B. Memory Optimization

Inkscape is a bit heavy in its memory use, and is tough to use on computers with limited RAM. This project would seek to analyze and understand Inkscape's memory usage, identify and correct all memory leaks, and decrease memory usage for typical cases. Ultimately, the project should result in Inkscape running smoothly on lower RAM systems than currently.

Mentor: MentalGuy

C. 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

D. 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.

Mentor: TBD

E. SVG Filters

Filters are a very important SVG capability, that allows giving special features to drawing objects, including shadows, blurs, etc. Inkscape currently does not support this capability, but it's high on the list of desires.

This project involves some rearchitecting of Inkscape's shape code to allow inclusion of filters, and requires implementing at least one filter, 'Gaussian blur' as a proof of concept.

Mentor: Bulia

F. Bucket fill tool

This feature provides a new tool that generates a vector object with the desired color. This would allow, for example, the artist to draw a set of intersecting lines, and paint the blank spaces in between.

Two approaches have been proposed: The first would export to a bitmap, perform a flood-fill, then trace the result and insert back into the drawing. The second would strive to detect the surrounding vector objects, extract their points, and then construct a matching shape with the desired fill. Both approaches have their pros and cons; please select either and explain why you wish to do it that way, and how you would do it.

More discussion is available here:

Mentor: Bulia

Adding bitmap 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 built into Inkscape.

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

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

Additional Ideas

  • External linking - Read/write support for external CSS, defs etc.
  • SVG support in OpenOffice (not exactly Inkscape development, but would allow Inkscape users to paste in art rather than having to export to png and really promote usuage of Inkscape). Not to mention eliminating all those duplicate svg/png image files!
  • More potrace/SIOX/etc. style features/development
  • Extending the online InkscapeSVG stuff - might be very cool for sharing sketches, etc
  • Building a public whiteboard server for Inkscape users, with a web site of its own, user galleries, interest groups, scheduled drawathons, connections to OCAL, etc.
  • Develop a prototype for a cross-platform open API to allow vector graphics tools to apply bitmap effects (e.g. from GIMP or ImageMagick) transparently to vector graphics.
  • Import/Export
Implement (I know of UberConverter (now VectorSection), but PDF is the most important interchange format so we should better support it natively)
Implement EPS import by reusing Scribus' EPS import library for Inkscape.
Create or enhance converters for file formats like Visio, CorelDraw, etc. etc.
Any of the above implemented as VectorSection connectors and/or anything on the VectorSection wishlist (likely mentors: EricWilhelm, ChrisSomerlot, BrunoPostle, ACSpike)
  • Skeletal Strokes and Effect Lines - A few links: Our wiki page on Expression [[1]], Technical papers on Skeletal Strokes [[2]], Examples - [[3]], [[4]], [[5]].
  • Standalone palette editor
  • Improvements to the text tool.
    • Some example ideas for improvements:
      • flowed text does not respect the default style of the text tool
      • when flowing a text which already contains line breaks, the line breaks are not conserved and are converted to spaces. It would be better to conserve them.
      • 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.
    • A general way to address this would be to rework the Text and Font dialog (and I think it was planned anyway):
      • It could include some kind of "story editor" a la Scribus instead of the Text tab. Then text editing and formatting could be done there avoiding the style erase mentioned above.
      • I don't know a font manager on linux but I guess there should be at least one. It would be nice to have some font collections before the font family selector, in order to narrow the search. I have over 300 fonts on my system (and I guess this is not much compared to some graphic designer) and it is already difficult to find the one I want in the Text and Font dialog. BTW: the Font family list is not searchable with the keyboard while every other GTK list I have seen is.

bbyak projects (mentored by bulia)

  • Color adjust dialog (brightness/contrast, HSL, "colorize") which would work on any number of vector objects (with flat, gradient, or pattern fill) as well as bitmaps

SOC 2005