Difference between revisions of "Google Summer of Code 2006"
|Line 152:||Line 152:|
* Converter from Flash (SWF) to VectorSection's CRS format
* Converter from Flash (SWF) to VectorSection's CRS format
=== SOC 2005 ===
=== SOC 2005 ===
Revision as of 07:30, 7 May 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.
A. PDF Export Extension
PDF is the most important graphic document interchange format, but Inkscape's current capability is woefully inadequate (we export to postscript and use ps2pdf). This project would focus on establishing a solid solution to this need.
An implementation approach for this would be to create a new Inkscape extension, "crs2pdf", which links to the Cairo library for PDF rendering capability, and to Vector Section for parsing the SVG into CRS.
This work may also require making some alterations to Cairo and/or VectorSection to improve the quality of the throughput.
The tool must successfully convert at least half of the about screens used in Inkscape versions 0.35-0.44. Major kudos if you can convert all of them.
B. EPS Import
While SVG is becoming a common format for exchanging data between graphics programs, EPS is currently much more common. Inkscape's current EPS support is flakey and poorly maintained. The plan is to switch to use of Scribus' EPS Import Library.
This project would involve creating a new Inkscape extension, "eps2crs", which links to Scribus' EPS import library and exports into the Vector Section CRS format.
This work may also require making some alterations to the Scribus PDF library and/or VectorSection to improve the quality of the throughput.
C. 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 major memory leaks, and decrease memory usage for typical cases by a nontrivial amount. Ultimately, the project should result in Inkscape running smoothly on lower RAM systems than currently.
D. 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)
E. 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.
F. 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 would consist of two parts: (1) adding a SPObject for filters and CSS support for referencing them; (2) adding renderer support for doing the actual filter effects when rendering. Completing this project requires implementing at least one filter, 'Gaussian blur' as a proof of concept.
G. 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 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.
- 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)
H. Inkscape / GIMP Bitmap 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. 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.
I. 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:
- Make flowed text respect the default style of the text tool
- 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.
- Search through the Inkscape RFE list for other text and font improvement ideas
J. 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.
K. External CSS Support
Inkscape currently supports inline CSS, but real support for editing non-inline CSS would allow for great functionality when storing style elements in the document head or an external file. Implemengting this would help prevent a lot of duplication of css and will greatly improve our ability to use SVG generated by other programs that use non-inline CSS.
L. 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 render the current image to a in-memory bitmap, perform a flood-fill (borrow the algorithm e.g. from Gimp), then trace the result and insert the resulting vector object into the drawing. The second would strive to detect the surrounding vector objects and perform a boolean path operation to 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: http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&group_id=93438&atid=604309
- 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.
- Skeletal Strokes and Effect Lines - A few links: Our wiki page on Expression [], Technical papers on Skeletal Strokes [], Examples - [], [], [].
- Improve the functionality and ease of use of the python effects API (see my proposal in the ImprovingPythonExtensionAPI page )
- Standalone palette editor
- Converter from Visio to VectorSection's CRS format
- Converter from CorelDraw (CDR) to VectorSection's CRS format
- Converter enhancements for VectorSection (dxf2rzp, rzp2dxf, rzp2crs, crs2rzp, etc.)
- Converter from Flash (SWF) to VectorSection's CRS format
- Implementation of scissors and razor tools. Yes, these blunt tools are so necessary to quickly cut paths.
- Add user profiles (some nice graphical interface) to store different sets of default metadata that can be used quickly
- upgrade the metadata and licensing dialogs with more options and general licenses checking (upgrade cc license selection to using web services