https://wiki.inkscape.org/wiki/api.php?action=feedcontributions&user=LionKimbro&feedformat=atomInkscape Wiki - User contributions [en]2024-03-28T19:55:01ZUser contributionsMediaWiki 1.36.1https://wiki.inkscape.org/wiki/index.php?title=Open_Clip_Art_Library_Integration&diff=14033Open Clip Art Library Integration2007-03-25T02:51:20Z<p>LionKimbro: notes on OCALhelper, from 2005</p>
<hr />
<div>This is an idea for 2 ways of integrating [[Inkscape]] with the [[OpenClipArtLibrary]] (OCAL.)<br />
<br />
== Keyed Search & Inclusion from OCAL ==<br />
<br />
When the user is making a drawing, the user thinks, "Oh, I need ''penguin'' clip-art here."<br />
<br />
It would be nice if the user could press a key sequence (Control-''N'', for some N,) and then type in the word "penguin." The user then has a penguin, selected, under the cursor.<br />
<br />
If that particular penguin won't do, the user can deleted it (delete key, as usual, to delete a selected item,) and then key in a new search (Control-''N'', key in "penguin baby,") or tap Control-Spacebar repeatedly to flip through different images tagged (or otherwise identified) "penguin."<br />
<br />
This idea is inspired by the way that character selection works for asian characters sets (Chinese, Kanji.)<br />
<br />
=== Multi-Library Support ===<br />
<br />
Ideally, the user could search from local libraries, in addition to the OCAL, or specify the library that is the source of inclusion. This way, the user can control what sorts of images will appear. (Similar to the idea of a "font," but for clipart -- ensuring that the images are the same style, license, and so on.)<br />
<br />
Tagged image libraries is, to me, an obvious and simple way of doing this.<br />
<br />
== Automated Publishing ==<br />
<br />
Have a system for saving directly to the OCAL.<br />
<br />
The system would likely engage in a dialog with the user. The dialog would explain what is happening, allow the user to programmatically register the clipart in the public domain, and collect information about the clipart from the user (author, tags, categories, ...)<br />
<br />
== Research Notes ==<br />
<br />
[http://www.google.com/search?q=Greg%20Steffensen Greg Steffensen] was working on something like this, and may be interested in developing the software, or perhaps has already implemented it; He may have [http://mail.gnome.org/archives/dia-list/2005-March/msg00115.html a current gmail address.]<br />
<br />
* [http://developer.berlios.de/projects/ocalhelper/ OCAL Helper], "A GTK interface for browsing and searching for clip art," registered 2005-Jun-27, source released Sep-21. [http://summerofclipart.blogspot.com/2005/08/w00t.html Blog Post] on it.<br />
<br />
== Author ==<br />
<br />
This page started by LionKimbro, 2006-12-18. Please contact by gmail if you have any supports for this idea, or are interested in developing it.</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=Google_Summer_of_Code_2007&diff=13925Google Summer of Code 20072007-03-12T00:37:03Z<p>LionKimbro: OpenClipArtLibraryIntegration.</p>
<hr />
<div>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.<br />
<br />
= Student Applications =<br />
<br />
* Google program information<br />
** GSoC Application form<br />
* Inkscape-specific information<br />
** [[SOC Application Template]]<br />
** [[Roadmap | Inkscape Roadmap]] - to see our overall objectives<br />
** [[SOC Writing Project Proposals]] - some guidelines for proposals<br />
** [[SOC Selection Criteria]] - how we rate applications<br />
<br />
= Project Ideas =<br />
<br />
== 3D capability ==<br />
<br />
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. <br />
<br />
* A '''3D box tool''' would be able to: <br />
<br />
:*draw a 3D box; <br />
<br />
:*adjust any of its 3 dimensions by handles and numerically; <br />
<br />
:*freely move the perspective vanishing point for each dimension; <br />
<br />
:*switch any dimension from a vanishing point to direction (point in infinity, lines are parallel) and back;<br />
<br />
:*Allow subdivision of each face to create perspective grids;<br />
<br />
:*when more than one 3D box is selected and their perspective is compatible, drag their common vanishing points/directions updating all selected boxes;<br />
<br />
:*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;<br />
<br />
:*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.<br />
<br />
: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).<br />
<br />
* '''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. <br />
<br />
* '''Other primitives''': Sphere, Cylinder, Cone, Pyramid ...<br />
<br />
* '''Perspective transform tool''' like in the GIMP<br />
<br />
* '''Perspective grid tiling''': cloning an object to each field of a grid.<br />
<br />
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.<br />
<br />
<b>Mentor:</b> bbyak<br />
<br />
== Native EPS and/or PDF Import ==<br />
<br />
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. <br />
<br />
Where the code can be borrowed from: <br />
<br />
*For EPS: Scribus' EPS Import Library<br />
<br />
*For PDF: poppler library<br />
<br />
*For both: Ghostscript (though it may be too heavy for us)<br />
<br />
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).<br />
<br />
<b>Mentor:</b> ???<br />
<br />
== Live Path Effects ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
* '''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.<br />
<br />
* '''Fractalize''' is currently a Python effect but would make a great live path effect. It can be useful in <b>mapmaking</b>; 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: [http://www.svgopen.org/2004/papers/AdaptiveLoD/ Adaptive Level of Detail in SVG].)<br />
<br />
<b>Mentor:</b> Aaron Spike<br />
<br />
== Native CDR (Corel Draw) import/export ==<br />
<br />
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. <br />
<br />
While CDR is not an open format, several open source implementations exist, from which you can borrow code:<br />
<br />
* Open source [http://xaralx.org/ Xara LX] can import and export CDR files.<br />
<br />
* [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. <br />
<br />
* 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).<br />
<br />
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.<br />
<br />
'''Mentor:''' bbyak<br />
<br />
== Inkboard Portability ==<br />
<br />
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.<br />
<br />
This work may involve [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/protocol/ formalizing and extending the Inkboard communication protocol] and [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/ working on the INKBOARD_PEDRO branch])<br />
<br />
<b>Mentor:</b> Ted<br />
<br />
== New Grids ==<br />
<br />
Inkscape currently has square grids that can be snapped to. Extend this to allow other kinds of grids: Perspective, hex, iso, etc.<br />
<br />
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.<br />
<br />
Requests in tracker:<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1591386&group_id=93438&atid=604309 Perspective Grid: 2 and 3 point with sample Perl script.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1005753&group_id=93438&atid=604309 Perspective Grid: 1, 2, and 3 point.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1418249&group_id=93438&atid=604309 Hex Grid.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1365504&group_id=93438&atid=604309 Isometric Grid.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=900270&group_id=93438&atid=604309 Isometric Grid.]<br />
<br />
<b>Mentor:</b> TBD<br />
<br />
<br />
<br />
== SVG Filters UI ==<br />
<br />
Filters are a very important [http://www.w3.org/TR/SVG/filters.html SVG capability].<br />
<br />
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.<br />
<br />
<b>Mentor:</b> Bulia<br />
<br />
== Adding bitmap capabilities to Inkscape ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<b>Project Timeline:</b><br />
<br />
* Implement first effect. This involves building Inkscape, linking in ImageMagick and getting one effect written (6 weeks)<br />
* Implement remaining effects within ImageMagick (3 weeks)<br />
* Build a test suite for operations and complete all Doxygen documentation of code (3 weeks)<br />
<br />
<b>Mentor:</b> Ted<br />
<br />
<br />
<br />
== Inkscape / GIMP Bitmap Editing Integration ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
As a proof of concept, the result should demonstrate this interoperability with GIMP and/or [http://www.gegl.org/ 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.<br />
<br />
Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=862655&group_id=93438&atid=604309<br />
<br />
<b>Mentor:</b> TBD<br />
<br />
== Text Tool Improvements ==<br />
<br />
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.<br />
<br />
Some ideas for improvements:<br />
* Make flowed text respect the default style of the text tool (a simple bugfix)<br />
* When flowing a text which already contains line breaks, provide a way for the line breaks to be conserved<br />
* 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. <br />
* Support [http://www.w3.org/TR/SVG11/text.html#TextDecorationProperties text-decoration] (underline, overline, line-through)<br />
* Better respect different faces of fonts (Light, Book, Normal, Black etc.)<br />
* 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.<br />
* Search through the Inkscape RFE list for other text and font improvement ideas<br />
<br />
See also: http://valessio.ul-jb.org/projetos/inkscape/inkscribus.htm<br />
<br />
<b>Mentor:</b> TBD<br />
<br />
<br />
== Color Adjustment Dialog ==<br />
<br />
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.<br />
<br />
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. <br />
<br />
<b>Mentor:</b> Bulia<br />
<br />
<br />
<br />
== SVG fonts support ==<br />
<br />
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. <br />
<br />
<b>Mentor:</b> ???<br />
<br />
<br />
<br />
== External CSS Support ==<br />
<br />
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.<br />
<br />
<b>Mentor:</b> Peter Moulder<br />
<br />
== Multi-page Support ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ccHost Import/Export ==<br />
<br />
Allow exporting to, or importing from, a remote ccHost instance.<br />
<br />
In particular, export to the [[OpenClipArtLibrary]], and import from said library (with some search terms, tag words, and perhaps even browsing.)<br />
<br />
[[LionKimbro]] can help someone spec out the capabilities, interfaces (both programmatic and GUI), and so on. He's written a little on [[OpenClipArtLibraryIntegration]] already. cell: 206.427.2545.<br />
<br />
= Past Years =<br />
<br />
* [[Googles Summer of Code 2006]]<br />
* Googles Summer of Code 2005<br />
** [[SOC Accepted Proposals]]<br />
** [[SOC Writing Project Proposals]]<br />
** [[SOC Selection Criteria]]<br />
** [[SOC Original Project Prompts]]</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=Google_Summer_of_Code_2007&diff=13924Google Summer of Code 20072007-03-12T00:30:48Z<p>LionKimbro: ccHost Import/Export</p>
<hr />
<div>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.<br />
<br />
= Student Applications =<br />
<br />
* Google program information<br />
** GSoC Application form<br />
* Inkscape-specific information<br />
** [[SOC Application Template]]<br />
** [[Roadmap | Inkscape Roadmap]] - to see our overall objectives<br />
** [[SOC Writing Project Proposals]] - some guidelines for proposals<br />
** [[SOC Selection Criteria]] - how we rate applications<br />
<br />
= Project Ideas =<br />
<br />
== 3D capability ==<br />
<br />
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. <br />
<br />
* A '''3D box tool''' would be able to: <br />
<br />
:*draw a 3D box; <br />
<br />
:*adjust any of its 3 dimensions by handles and numerically; <br />
<br />
:*freely move the perspective vanishing point for each dimension; <br />
<br />
:*switch any dimension from a vanishing point to direction (point in infinity, lines are parallel) and back;<br />
<br />
:*Allow subdivision of each face to create perspective grids;<br />
<br />
:*when more than one 3D box is selected and their perspective is compatible, drag their common vanishing points/directions updating all selected boxes;<br />
<br />
:*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;<br />
<br />
:*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.<br />
<br />
: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).<br />
<br />
* '''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. <br />
<br />
* '''Other primitives''': Sphere, Cylinder, Cone, Pyramid ...<br />
<br />
* '''Perspective transform tool''' like in the GIMP<br />
<br />
* '''Perspective grid tiling''': cloning an object to each field of a grid.<br />
<br />
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.<br />
<br />
<b>Mentor:</b> bbyak<br />
<br />
== Native EPS and/or PDF Import ==<br />
<br />
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. <br />
<br />
Where the code can be borrowed from: <br />
<br />
*For EPS: Scribus' EPS Import Library<br />
<br />
*For PDF: poppler library<br />
<br />
*For both: Ghostscript (though it may be too heavy for us)<br />
<br />
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).<br />
<br />
<b>Mentor:</b> ???<br />
<br />
== Live Path Effects ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
* '''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.<br />
<br />
* '''Fractalize''' is currently a Python effect but would make a great live path effect. It can be useful in <b>mapmaking</b>; 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: [http://www.svgopen.org/2004/papers/AdaptiveLoD/ Adaptive Level of Detail in SVG].)<br />
<br />
<b>Mentor:</b> Aaron Spike<br />
<br />
== Native CDR (Corel Draw) import/export ==<br />
<br />
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. <br />
<br />
While CDR is not an open format, several open source implementations exist, from which you can borrow code:<br />
<br />
* Open source [http://xaralx.org/ Xara LX] can import and export CDR files.<br />
<br />
* [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. <br />
<br />
* 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).<br />
<br />
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.<br />
<br />
'''Mentor:''' bbyak<br />
<br />
== Inkboard Portability ==<br />
<br />
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.<br />
<br />
This work may involve [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/protocol/ formalizing and extending the Inkboard communication protocol] and [http://svn.sourceforge.net/viewcvs.cgi/inkscape/inkscape/branches/INKBOARD_PEDRO/src/jabber_whiteboard/ working on the INKBOARD_PEDRO branch])<br />
<br />
<b>Mentor:</b> Ted<br />
<br />
== New Grids ==<br />
<br />
Inkscape currently has square grids that can be snapped to. Extend this to allow other kinds of grids: Perspective, hex, iso, etc.<br />
<br />
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.<br />
<br />
Requests in tracker:<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1591386&group_id=93438&atid=604309 Perspective Grid: 2 and 3 point with sample Perl script.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1005753&group_id=93438&atid=604309 Perspective Grid: 1, 2, and 3 point.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1418249&group_id=93438&atid=604309 Hex Grid.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=1365504&group_id=93438&atid=604309 Isometric Grid.]<br />
*[http://sourceforge.net/tracker/index.php?func=detail&aid=900270&group_id=93438&atid=604309 Isometric Grid.]<br />
<br />
<b>Mentor:</b> TBD<br />
<br />
<br />
<br />
== SVG Filters UI ==<br />
<br />
Filters are a very important [http://www.w3.org/TR/SVG/filters.html SVG capability].<br />
<br />
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.<br />
<br />
<b>Mentor:</b> Bulia<br />
<br />
== Adding bitmap capabilities to Inkscape ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<b>Project Timeline:</b><br />
<br />
* Implement first effect. This involves building Inkscape, linking in ImageMagick and getting one effect written (6 weeks)<br />
* Implement remaining effects within ImageMagick (3 weeks)<br />
* Build a test suite for operations and complete all Doxygen documentation of code (3 weeks)<br />
<br />
<b>Mentor:</b> Ted<br />
<br />
<br />
<br />
== Inkscape / GIMP Bitmap Editing Integration ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
As a proof of concept, the result should demonstrate this interoperability with GIMP and/or [http://www.gegl.org/ 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.<br />
<br />
Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=862655&group_id=93438&atid=604309<br />
<br />
<b>Mentor:</b> TBD<br />
<br />
== Text Tool Improvements ==<br />
<br />
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.<br />
<br />
Some ideas for improvements:<br />
* Make flowed text respect the default style of the text tool (a simple bugfix)<br />
* When flowing a text which already contains line breaks, provide a way for the line breaks to be conserved<br />
* 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. <br />
* Support [http://www.w3.org/TR/SVG11/text.html#TextDecorationProperties text-decoration] (underline, overline, line-through)<br />
* Better respect different faces of fonts (Light, Book, Normal, Black etc.)<br />
* 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.<br />
* Search through the Inkscape RFE list for other text and font improvement ideas<br />
<br />
See also: http://valessio.ul-jb.org/projetos/inkscape/inkscribus.htm<br />
<br />
<b>Mentor:</b> TBD<br />
<br />
<br />
== Color Adjustment Dialog ==<br />
<br />
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.<br />
<br />
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. <br />
<br />
<b>Mentor:</b> Bulia<br />
<br />
<br />
<br />
== SVG fonts support ==<br />
<br />
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. <br />
<br />
<b>Mentor:</b> ???<br />
<br />
<br />
<br />
== External CSS Support ==<br />
<br />
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.<br />
<br />
<b>Mentor:</b> Peter Moulder<br />
<br />
== Multi-page Support ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ccHost Import/Export ==<br />
<br />
Allow exporting to, or importing from, a remote ccHost instance.<br />
<br />
In particular, export to the OpenClipArtLibrary, and import from said library (with some search terms, tag words, and perhaps even browsing.)<br />
<br />
LionKimbro can help someone spec out the capabilities, interfaces (both programmatic and GUI), and so on.<br />
<br />
= Past Years =<br />
<br />
* [[Googles Summer of Code 2006]]<br />
* Googles Summer of Code 2005<br />
** [[SOC Accepted Proposals]]<br />
** [[SOC Writing Project Proposals]]<br />
** [[SOC Selection Criteria]]<br />
** [[SOC Original Project Prompts]]</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=Open_Clip_Art_Library_Integration&diff=12332Open Clip Art Library Integration2006-12-18T20:34:38Z<p>LionKimbro: </p>
<hr />
<div>This is an idea for 2 ways of integrating [[Inkscape]] with the [[OpenClipArtLibrary]] (OCAL.)<br />
<br />
== Keyed Search & Inclusion from OCAL ==<br />
<br />
When the user is making a drawing, the user thinks, "Oh, I need ''penguin'' clip-art here."<br />
<br />
It would be nice if the user could press a key sequence (Control-''N'', for some N,) and then type in the word "penguin." The user then has a penguin, selected, under the cursor.<br />
<br />
If that particular penguin won't do, the user can deleted it (delete key, as usual, to delete a selected item,) and then key in a new search (Control-''N'', key in "penguin baby,") or tap Control-Spacebar repeatedly to flip through different images tagged (or otherwise identified) "penguin."<br />
<br />
This idea is inspired by the way that character selection works for asian characters sets (Chinese, Kanji.)<br />
<br />
=== Multi-Library Support ===<br />
<br />
Ideally, the user could search from local libraries, in addition to the OCAL, or specify the library that is the source of inclusion. This way, the user can control what sorts of images will appear. (Similar to the idea of a "font," but for clipart -- ensuring that the images are the same style, license, and so on.)<br />
<br />
Tagged image libraries is, to me, an obvious and simple way of doing this.<br />
<br />
== Automated Publishing ==<br />
<br />
Have a system for saving directly to the OCAL.<br />
<br />
The system would likely engage in a dialog with the user. The dialog would explain what is happening, allow the user to programmatically register the clipart in the public domain, and collect information about the clipart from the user (author, tags, categories, ...)<br />
<br />
== Author ==<br />
<br />
This page started by LionKimbro, 2006-12-18.</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=Open_Clip_Art_Library_Integration&diff=12330Open Clip Art Library Integration2006-12-18T20:34:18Z<p>LionKimbro: pull penguin images from OCAL by typing, "Control-(something) penguin"</p>
<hr />
<div>This is an idea for 2 ways of integrating [[Inkscape]] with the OpenClipArtLibrary (OCAL.)<br />
<br />
== Keyed Search & Inclusion from OCAL ==<br />
<br />
When the user is making a drawing, the user thinks, "Oh, I need ''penguin'' clip-art here."<br />
<br />
It would be nice if the user could press a key sequence (Control-''N'', for some N,) and then type in the word "penguin." The user then has a penguin, selected, under the cursor.<br />
<br />
If that particular penguin won't do, the user can deleted it (delete key, as usual, to delete a selected item,) and then key in a new search (Control-''N'', key in "penguin baby,") or tap Control-Spacebar repeatedly to flip through different images tagged (or otherwise identified) "penguin."<br />
<br />
This idea is inspired by the way that character selection works for asian characters sets (Chinese, Kanji.)<br />
<br />
=== Multi-Library Support ===<br />
<br />
Ideally, the user could search from local libraries, in addition to the OCAL, or specify the library that is the source of inclusion. This way, the user can control what sorts of images will appear. (Similar to the idea of a "font," but for clipart -- ensuring that the images are the same style, license, and so on.)<br />
<br />
Tagged image libraries is, to me, an obvious and simple way of doing this.<br />
<br />
== Automated Publishing ==<br />
<br />
Have a system for saving directly to the OCAL.<br />
<br />
The system would likely engage in a dialog with the user. The dialog would explain what is happening, allow the user to programmatically register the clipart in the public domain, and collect information about the clipart from the user (author, tags, categories, ...)<br />
<br />
== Author ==<br />
<br />
This page started by LionKimbro, 2006-12-18.</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5559WikiExporter2005-02-15T07:06:28Z<p>LionKimbro: * Two way now-- Can both save to wiki, and load back from wiki.</p>
<hr />
<div>I've written a bunch of little scripts that, together, make it so you can save to and load from an [http://www.oddmuse.org/cgi-bin/wiki OddMuse] wiki.<br />
<br />
It renders out both Inkscape .svg and .png versions of the data.<br />
<br />
You can load from the wiki, make a few edits, hit "Ctrl-S," and the edited document is sent back to the wiki.<br />
<br />
It's fun!<br />
<br />
----<br />
<br />
(I believe that means it should work for ''this'' wiki, as well, though I haven't tried it.)<br />
<br />
Basically, it goes like this:<br />
* A script is called from Inkscape when the user saves,<br />
* the script reads the SVG document to figure out what directory it was saved to,<br />
* the script reads it to figure out what filename was used as well,<br />
* information about the target wiki is read from the directory the SVG was saved to,<br />
* the Inkscape SVG is uploaded to the wiki,<br />
* and a PNG version is uploaded to the wiki as well.<br />
<br />
This all requires 4 files:<br />
* odd_output.inx -- Inkscape extension definition<br />
* svg2oddmuse.sh -- coordinates most everything<br />
* svgattrs.py -- scans the SVG file for <svg ...> attributes<br />
* wikiupload.py -- oddmuse upload script<br />
<br />
Furthermore, the user creates a custom file, "notes.txt".<br />
The file details the username and wiki URL for svg2oddmuse.sh.<br />
<br />
The [http://www.emacswiki.org/cw/InkscapeToOddmuse full description of how it works] is on [http://communitywiki.org/ CommunityWiki.]<br />
<br />
Next, I intend to write code to ''read'' Inkscape SVG from the wiki as well.<br />
<br />
The process is kind of hacky; I imagine that when one of the ExtensionArchitectureProposals is chosen and implemented, it'll be a lot nicer.<br />
<br />
'''Drawing Area?'''<br />
<br />
Right now, I've hard coded it to export the ''page.''<br />
<br />
The relevant code looks like this:<br />
<br />
inkscape --file="$INK_SVG" --export-png="$DOCBASE/$DOCNAME.png" --export-area "0:0:595.28:841.89" > /dev/null<br />
<br />
I tried removing the --export-area, and all I got were tiny little 123 byte files.<br />
<br />
Ideally, my code would send off only the ''drawing,'' not the whole page.<br />
<br />
Questions:<br />
* Does the CLI interface support this in version 0.40? (Maybe I'm just missing it.)<br />
* Is there a way I can easily get the information from the SVG? (Maybe I'm just missing it.)<br />
<br />
'''Bitmaps to data URLs?'''<br />
<br />
I saw in the examples, that a PNG was turned into a binary64 encoded data URL.<br />
<br />
I haven't written the code to locate PNG references, and replace them with data URLs.<br />
<br />
But, this is something that I think should be done with it.<br />
<br />
Question:<br />
* Is there a way to turn PNG images into data: URLs ''within Inkscape?''<br />
* From the CLI?</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5568WikiExporter2005-02-13T10:20:43Z<p>LionKimbro: * will probably work on *this* wiki..!</p>
<hr />
<div>I've written 4 files that, together, make it so you can save to an [http://www.oddmuse.org/cgi-bin/wiki OddMuse] wiki.<br />
<br />
(I believe that means it should work for ''this'' wiki, as well, though I haven't tried it.)<br />
<br />
Basically, it goes like this:<br />
* A script is called from Inkscape when the user saves,<br />
* the script reads the SVG document to figure out what directory it was saved to,<br />
* the script reads it to figure out what filename was used as well,<br />
* information about the target wiki is read from the directory the SVG was saved to,<br />
* the Inkscape SVG is uploaded to the wiki,<br />
* and a PNG version is uploaded to the wiki as well.<br />
<br />
This all requires 4 files:<br />
* odd_output.inx -- Inkscape extension definition<br />
* svg2oddmuse.sh -- coordinates most everything<br />
* svgattrs.py -- scans the SVG file for <svg ...> attributes<br />
* wikiupload.py -- oddmuse upload script<br />
<br />
Furthermore, the user creates a custom file, "notes.txt".<br />
The file details the username and wiki URL for svg2oddmuse.sh.<br />
<br />
The [http://www.emacswiki.org/cw/InkscapeToOddmuse full description of how it works] is on [http://communitywiki.org/ CommunityWiki.]<br />
<br />
Next, I intend to write code to ''read'' Inkscape SVG from the wiki as well.<br />
<br />
The process is kind of hacky; I imagine that when one of the ExtensionArchitectureProposals is chosen and implemented, it'll be a lot nicer.<br />
<br />
'''Drawing Area?'''<br />
<br />
Right now, I've hard coded it to export the ''page.''<br />
<br />
The relevant code looks like this:<br />
<br />
inkscape --file="$INK_SVG" --export-png="$DOCBASE/$DOCNAME.png" --export-area "0:0:595.28:841.89" > /dev/null<br />
<br />
I tried removing the --export-area, and all I got were tiny little 123 byte files.<br />
<br />
Ideally, my code would send off only the ''drawing,'' not the whole page.<br />
<br />
Questions:<br />
* Does the CLI interface support this in version 0.40? (Maybe I'm just missing it.)<br />
* Is there a way I can easily get the information from the SVG? (Maybe I'm just missing it.)<br />
<br />
'''Bitmaps to data URLs?'''<br />
<br />
I saw in the examples, that a PNG was turned into a binary64 encoded data URL.<br />
<br />
I haven't written the code to locate PNG references, and replace them with data URLs.<br />
<br />
But, this is something that I think should be done with it.<br />
<br />
Question:<br />
* Is there a way to turn PNG images into data: URLs ''within Inkscape?''<br />
* From the CLI?</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5567WikiExporter2005-02-13T10:19:24Z<p>LionKimbro: * questions about CLI export area control, bitmap conversion to data URLs</p>
<hr />
<div>I've written 4 files that, together, make it so you can save to an [http://www.oddmuse.org/cgi-bin/wiki OddMuse] wiki.<br />
<br />
Basically, it goes like this:<br />
* A script is called from Inkscape when the user saves,<br />
* the script reads the SVG document to figure out what directory it was saved to,<br />
* the script reads it to figure out what filename was used as well,<br />
* information about the target wiki is read from the directory the SVG was saved to,<br />
* the Inkscape SVG is uploaded to the wiki,<br />
* and a PNG version is uploaded to the wiki as well.<br />
<br />
This all requires 4 files:<br />
* odd_output.inx -- Inkscape extension definition<br />
* svg2oddmuse.sh -- coordinates most everything<br />
* svgattrs.py -- scans the SVG file for <svg ...> attributes<br />
* wikiupload.py -- oddmuse upload script<br />
<br />
Furthermore, the user creates a custom file, "notes.txt".<br />
The file details the username and wiki URL for svg2oddmuse.sh.<br />
<br />
The [http://www.emacswiki.org/cw/InkscapeToOddmuse full description of how it works] is on [http://communitywiki.org/ CommunityWiki.]<br />
<br />
Next, I intend to write code to ''read'' Inkscape SVG from the wiki as well.<br />
<br />
The process is kind of hacky; I imagine that when one of the ExtensionArchitectureProposals is chosen and implemented, it'll be a lot nicer.<br />
<br />
'''Drawing Area?'''<br />
<br />
Right now, I've hard coded it to export the ''page.''<br />
<br />
The relevant code looks like this:<br />
<br />
inkscape --file="$INK_SVG" --export-png="$DOCBASE/$DOCNAME.png" --export-area "0:0:595.28:841.89" > /dev/null<br />
<br />
I tried removing the --export-area, and all I got were tiny little 123 byte files.<br />
<br />
Ideally, my code would send off only the ''drawing,'' not the whole page.<br />
<br />
Questions:<br />
* Does the CLI interface support this in version 0.40? (Maybe I'm just missing it.)<br />
* Is there a way I can easily get the information from the SVG? (Maybe I'm just missing it.)<br />
<br />
'''Bitmaps to data URLs?'''<br />
<br />
I saw in the examples, that a PNG was turned into a binary64 encoded data URL.<br />
<br />
I haven't written the code to locate PNG references, and replace them with data URLs.<br />
<br />
But, this is something that I think should be done with it.<br />
<br />
Question:<br />
* Is there a way to turn PNG images into data: URLs ''within Inkscape?''<br />
* From the CLI?</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5566WikiExporter2005-02-13T10:09:57Z<p>LionKimbro: *success! summary, how it works</p>
<hr />
<div>I've written 4 files that, together, make it so you can save to an [http://www.oddmuse.org/cgi-bin/wiki OddMuse] wiki.<br />
<br />
Basically, it goes like this:<br />
* A script is called from Inkscape when the user saves,<br />
* the script reads the SVG document to figure out what directory it was saved to,<br />
* the script reads it to figure out what filename was used as well,<br />
* information about the target wiki is read from the directory the SVG was saved to,<br />
* the Inkscape SVG is uploaded to the wiki,<br />
* and a PNG version is uploaded to the wiki as well.<br />
<br />
This all requires 4 files:<br />
* odd_output.inx -- Inkscape extension definition<br />
* svg2oddmuse.sh -- coordinates most everything<br />
* svgattrs.py -- scans the SVG file for <svg ...> attributes<br />
* wikiupload.py -- oddmuse upload script<br />
<br />
Furthermore, the user creates a custom file, "notes.txt".<br />
The file details the username and wiki URL for svg2oddmuse.sh.<br />
<br />
The [http://www.emacswiki.org/cw/InkscapeToOddmuse full description of how it works] is on [http://communitywiki.org/ CommunityWiki.]<br />
<br />
Next, I intend to write code to ''read'' Inkscape SVG from the wiki as well.</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=Extension_architecture_proposals&diff=1312Extension architecture proposals2005-02-13T03:22:34Z<p>LionKimbro: *revert</p>
<hr />
<div>Please place your extension architecture proposals here. Everyone will review them and we will decided a course of action after we release 0.38.<br />
<br />
* ExtensionArchProposal<br />
<br />
=== Tasks ===<br />
<br />
Design Phase:<br />
* Flesh out each category of functions in the API with ideas for what the functions should be<br />
* Solidify the underlying Extension infrastructure [Ted]<br />
* Create an example Extension package<br />
* Write a specification document, including:<br />
** Overview of Inkscape Extensions<br />
** Creating an Extension<br />
** Registering an Extension<br />
** Custom Extension Preferences<br />
** Extension API Definition<br />
<br />
Implementation Phase:<br />
* Implement Extension API<br />
* Implement an Extension registry<br />
* Create Extension preferences dialog<br />
* Create web tool for contributing new Extensions<br />
<br />
<br />
=== Requirements ===<br />
<br />
We would like the extension system to provide the following capabilities:<br />
<br />
* Uses a general language binding system so it's easy to add new language binding support<br />
* Allows direct interaction with the document object model including changing styles, adding/removing defs and elements, etc.<br />
* Allows some limited interaction with the Inkscape UI such as manipulating grids, overlays, etc.<br />
* Allows direct interaction with file load/save/export/print subsystem<br />
* Guaranteed to work properly with the undo system, even if the extension is not written carefully<br />
* Well documented so is easy for people to learn how to make new extensions<br />
* Each plugin can be implemented, distributed, and managed independently of the core project<br />
* Should be easy to start learning how to create new plugins<br />
* Icons, buttons, and other UI elements for plugins fit seamlessly into main application GUI<br />
* User can easily select which plugins to automatically load into application at startup<br />
* Loading of plugins shall not seriously slow startup time or make a major impact on memory footprint<br />
* Failure of a plugin shall not leave the drawing in an inconsistent state<br />
* Main application must gracefully recover from plugin crashes or other serious problems with plugin execution<br />
* Dependencies for particular plugins must be clearly identified for user if missing<br />
<br />
=== Extension ideas ===<br />
<br />
* Cross stitch generator (http://hawthorn.csse.monash.edu.au/~njh/programming/cross-stitch/)<br />
* Celtic knot editor: Using the standard winding number algorithm for Celtic knots build an interactive editor that forms the basic structure of the knots, allowing the user to edit the curve once generated. (Possible issue - getting the over/under rules correct) Douglas Zongker's Celtic Knot Thingy is a possible resource: http://isotropic.org/uw/knot/<br />
* Collection of symbols, similar to xfig's (map symbols? flags of the world)<br />
* mail-merge<br />
* Integration of [http://autotrace.sf.net Autotrace] so that one can click on a bitmap and say 'Vectorize'<br />
* Integrate a capture of a Blender3D frame and then process that bitmap. From a Blender-viewer window? From a simpler viewer? Not from a screen capture...higher resolution is desired...<br />
* Socket connection to other apps instead of file-based, where the state of socket connections will be autosaved and restorable after a crash...(since such on the fly work may not be easy to recreate then)<br />
* 3-d rotate - this is a really cool Kai (Kai's Vector Tools/Effects) plug-in for Illustrator<br />
* Inkify - it would be cool to have a plug-in that would take a normal object and make it look like it was drawn with ink.<br />
* Copy Adobe Illustrator's filters (punkify, bloat, calligraphize, etc)<br />
* Copy Dia's plugins<br />
* Look at Karbon14's plugins<br />
* PDF and Postscript import that converts all the type into lines as well as the included postscript vector objects and bitmaps<br />
* Randomize Size and Rotation of Objects<br />
* Create Cluster of objects from one seed with variable quantity, random distribution (noise types, gaussian, etc), variable rotation, opacity, and size<br />
* Zoom effect on shapes. Create an option where a zoom-like effect can be applied to a shape or set of shapes where more shapes are made larger and larger from the central anchor point of the shape(s) passed to this plugin<br />
<br />
<br />
=== Inkscape Extension Archive Network ===<br />
<br />
Initially, distributing extensions with Inkscape itself will be okay but ultimately for them to truly be extensions they should exist external to the core Inkscape project, which means we need some way to receive and manage contributions. Perl's CPAN provides an excellent model for how this type of module-contribution system can be made to work. Some important characteristics of CPAN worth adopting here:<br />
<br />
* Indexes of best items are available (e.g. 'best of')<br />
* Redundant modules are tolerated<br />
* Automate testing of included test suites on various platforms<br />
* Naming requirements to be included in indexes<br />
* Removal of malicious items<br />
* Manual application for user id on the system<br />
* Documentation for each module is online and nicely formatted<br />
* Integrated bug tracking system<br />
* Need to divide 'development' and 'stable'<br />
* Need to identify poor style, over-complexity.<br />
* Feedback to author should be personal so avoids public ranting<br />
* Use of review forms instead of freeform feedback?<br />
* Use of per-module discussion forums?<br />
* Establish forum for thanks and positive feedback<br />
* Like freshmeat/sourceforge, report on # downloads, vitality, etc.<br />
<br />
=== See Also ===<br />
* ScriptingHOWTO<br />
* [http://sourceforge.net/mailarchive/message.php?msg_id=2057634 Ted's Plug-in Research from SodiPodi]</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5565WikiExporter2005-02-12T23:32:54Z<p>LionKimbro: * docpath -> docbase</p>
<hr />
<div>These are LionKimbro's notes on developing a wiki exporter.<br />
<br />
Date: 2004-02-12<br />
Inkscape version: 0.40<br />
Target: Oddmuse<br />
<br />
That is, a system so that you can load from and save to a wiki.<br />
<br />
The wiki targetted by this exporter is Oddmuse. We have [http://www.oddmuse.org/cgi-bin/oddmuse/Automatic_Posting_and_Uploading#wikiupload an upload script for it.]<br />
<br />
I imagine it should be possible to use the Wiki XML-RPC interfaces as well, in the future, though they are usually turned off.<br />
<br />
'''odd_output.inx'''<br />
<br />
This file goes in: /usr/share/inkscape/extensions<br />
<br />
<inkscape-extension><br />
<name>Oddwiki Output</name><br />
<id>org.inkscape.output.odd</id><br />
<dependency type="executable" location="extensions">svg2oddmuse.sh</dependency><br />
<output><br />
<extension>.odd</extension><br />
<mimetype>image/x-svgz</mimetype><br />
<filetypename>Oddmuse Wiki POST (*.odd)</filetypename><br />
<filetypetooltip>Oddmuse Wiki proxy (SVG, PNG of Drawing)</filetypetooltip><br />
<dataloss>FALSE</dataloss><br />
</output><br />
<script><br />
<command reldir="extensions">svg2oddmuse.sh</command><br />
<helper_extension>org.inkscape.output.svg.inkscape</helper_extension><br />
</script><br />
</inkscape-extension><br />
<br />
'''What data am I receiving from Inkscape?'''<br />
<br />
To see what you're getting from Inkscape, create the following script, and call it: '''svg2oddmuse.sh'''<br />
<br />
#!/bin/bash<br />
echo "hello, world" > /tmp/eraseme.txt<br />
echo "invocation: $@"<br />
echo<br />
echo "$1:"<br />
cat "$1"<br />
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - -"<br />
env<br />
<br />
It appears that no environment variables are being set. The first (and only) argument is the location of a file in /tmp that contains the Inkscape SVG data.<br />
<br />
'''Now what?'''<br />
<br />
The strategy is this:<br />
<br />
* create a directory, representing the wiki<br />
* place a file in the directory, "oddmuse.txt", representing necessary details about the wiki<br />
* when the user saves a file to the directory (.odd extension,) do the following:<br />
** push the SVG to the wiki<br />
** render a PNG, and push the PNG to the wiki<br />
** perhaps append the name of the wikipage containing the SVG to a page on the wiki<br />
<br />
We don't have command-line access (bash argument, environment variable) to the filename or<br />
directory it was saved in. But we CAN get this data from the Inkscape SVG.<br />
<br />
The <svg> element has attributes:<br />
* "sodipodi:docbase" -- path up to the save location<br />
* "sodpodi:docname" -- filaname, including extension (".odd", in this case)<br />
<br />
<br />
== Inkscape Export process ==<br />
<br />
* User hits "Save" in "Save As" dialog<br />
* Inkscape writes a file with a random name to /tmp<br />
* Inkscape calls export bash script, with /tmp file as only argument<br />
* Whatever bash outputs to /dev/stdout, Inkscape records to the file chosen by the user.<br />
<br />
== Inkscape SVG Attributes ==<br />
<br />
Here's a Python script that outputs <svg> attributes:<br />
<br />
'''svgattrs.py''':<br />
<br />
#!/usr/bin/python2.3<br />
"""Expose Inkscape SVG attributes.<br />
<br />
Read an Inkscape SVG from stdin.<br />
Output attributes to the "<svg>" element to stdout.<br />
"""<br />
<br />
import sys<br />
import xml.sax<br />
<br />
<br />
class InkscapeSvgHandler(xml.sax.ContentHandler):<br />
<br />
"""Print attributes to svg element."""<br />
<br />
def startElement(self, name, attrs):<br />
if name == "svg":<br />
for (k,v) in attrs.items():<br />
print k + " " + v<br />
<br />
<br />
if __name__ == "__main__":<br />
parser = xml.sax.make_parser()<br />
parser.setContentHandler(InkscapeSvgHandler())<br />
parser.parse(sys.stdin)<br />
sys.exit(0)<br />
<br />
You can use it like so:<br />
<br />
DOCNAME=`cat "$1" | ./svgattrs.py | grep -e "^sodipodi:docname" | cut -d" " -f2`<br />
DOCBASE=`cat "$1" | ./svgattrs.py | grep -e "^sodipodi:docbase" | cut -d" " -f2`</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5564WikiExporter2005-02-12T22:37:57Z<p>LionKimbro: *Python script for getting the exported file's name & path</p>
<hr />
<div>These are LionKimbro's notes on developing a wiki exporter.<br />
<br />
Date: 2004-02-12<br />
Inkscape version: 0.40<br />
Target: Oddmuse<br />
<br />
That is, a system so that you can load from and save to a wiki.<br />
<br />
The wiki targetted by this exporter is Oddmuse. We have [http://www.oddmuse.org/cgi-bin/oddmuse/Automatic_Posting_and_Uploading#wikiupload an upload script for it.]<br />
<br />
I imagine it should be possible to use the Wiki XML-RPC interfaces as well, in the future, though they are usually turned off.<br />
<br />
'''odd_output.inx'''<br />
<br />
This file goes in: /usr/share/inkscape/extensions<br />
<br />
<inkscape-extension><br />
<name>Oddwiki Output</name><br />
<id>org.inkscape.output.odd</id><br />
<dependency type="executable" location="extensions">svg2oddmuse.sh</dependency><br />
<output><br />
<extension>.odd</extension><br />
<mimetype>image/x-svgz</mimetype><br />
<filetypename>Oddmuse Wiki POST (*.odd)</filetypename><br />
<filetypetooltip>Oddmuse Wiki proxy (SVG, PNG of Drawing)</filetypetooltip><br />
<dataloss>FALSE</dataloss><br />
</output><br />
<script><br />
<command reldir="extensions">svg2oddmuse.sh</command><br />
<helper_extension>org.inkscape.output.svg.inkscape</helper_extension><br />
</script><br />
</inkscape-extension><br />
<br />
'''What data am I receiving from Inkscape?'''<br />
<br />
To see what you're getting from Inkscape, create the following script, and call it: '''svg2oddmuse.sh'''<br />
<br />
#!/bin/bash<br />
echo "hello, world" > /tmp/eraseme.txt<br />
echo "invocation: $@"<br />
echo<br />
echo "$1:"<br />
cat "$1"<br />
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - -"<br />
env<br />
<br />
It appears that no environment variables are being set. The first (and only) argument is the location of a file in /tmp that contains the Inkscape SVG data.<br />
<br />
'''Now what?'''<br />
<br />
The strategy is this:<br />
<br />
* create a directory, representing the wiki<br />
* place a file in the directory, "oddmuse.txt", representing necessary details about the wiki<br />
* when the user saves a file to the directory (.odd extension,) do the following:<br />
** push the SVG to the wiki<br />
** render a PNG, and push the PNG to the wiki<br />
** perhaps append the name of the wikipage containing the SVG to a page on the wiki<br />
<br />
We don't have command-line access (bash argument, environment variable) to the filename or<br />
directory it was saved in. But we CAN get this data from the Inkscape SVG.<br />
<br />
The <svg> element has attributes:<br />
* "sodipodi:docbase" -- path up to the save location<br />
* "sodpodi:docname" -- filaname, including extension (".odd", in this case)<br />
<br />
<br />
== Inkscape Export process ==<br />
<br />
* User hits "Save" in "Save As" dialog<br />
* Inkscape writes a file with a random name to /tmp<br />
* Inkscape calls export bash script, with /tmp file as only argument<br />
* Whatever bash outputs to /dev/stdout, Inkscape records to the file chosen by the user.<br />
<br />
== Inkscape SVG Attributes ==<br />
<br />
Here's a Python script that outputs <svg> attributes:<br />
<br />
'''svgattrs.py''':<br />
<br />
#!/usr/bin/python2.3<br />
"""Expose Inkscape SVG attributes.<br />
<br />
Read an Inkscape SVG from stdin.<br />
Output attributes to the "<svg>" element to stdout.<br />
"""<br />
<br />
import sys<br />
import xml.sax<br />
<br />
<br />
class InkscapeSvgHandler(xml.sax.ContentHandler):<br />
<br />
"""Print attributes to svg element."""<br />
<br />
def startElement(self, name, attrs):<br />
if name == "svg":<br />
for (k,v) in attrs.items():<br />
print k + " " + v<br />
<br />
<br />
if __name__ == "__main__":<br />
parser = xml.sax.make_parser()<br />
parser.setContentHandler(InkscapeSvgHandler())<br />
parser.parse(sys.stdin)<br />
sys.exit(0)<br />
<br />
You can use it like so:<br />
<br />
DOCNAME=`cat "$1" | ./svgattrs.py | grep -e "^sodipodi:docname" | cut -d" " -f2`<br />
DOCPATH=`cat "$1" | ./svgattrs.py | grep -e "^sodipodi:docpath" | cut -d" " -f2`</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5563WikiExporter2005-02-12T21:04:57Z<p>LionKimbro: * SVG element</p>
<hr />
<div>These are LionKimbro's notes on developing a wiki exporter.<br />
<br />
Date: 2004-02-12<br />
Inkscape version: 0.40<br />
Target: Oddmuse<br />
<br />
That is, a system so that you can load from and save to a wiki.<br />
<br />
The wiki targetted by this exporter is Oddmuse. We have [http://www.oddmuse.org/cgi-bin/oddmuse/Automatic_Posting_and_Uploading#wikiupload an upload script for it.]<br />
<br />
I imagine it should be possible to use the Wiki XML-RPC interfaces as well, in the future, though they are usually turned off.<br />
<br />
'''odd_output.inx'''<br />
<br />
This file goes in: /usr/share/inkscape/extensions<br />
<br />
<inkscape-extension><br />
<name>Oddwiki Output</name><br />
<id>org.inkscape.output.odd</id><br />
<dependency type="executable" location="extensions">svg2oddmuse.sh</dependency><br />
<output><br />
<extension>.odd</extension><br />
<mimetype>image/x-svgz</mimetype><br />
<filetypename>Oddmuse Wiki POST (*.odd)</filetypename><br />
<filetypetooltip>Oddmuse Wiki proxy (SVG, PNG of Drawing)</filetypetooltip><br />
<dataloss>FALSE</dataloss><br />
</output><br />
<script><br />
<command reldir="extensions">svg2oddmuse.sh</command><br />
<helper_extension>org.inkscape.output.svg.inkscape</helper_extension><br />
</script><br />
</inkscape-extension><br />
<br />
'''What data am I receiving from Inkscape?'''<br />
<br />
To see what you're getting from Inkscape, create the following script, and call it: '''svg2oddmuse.sh'''<br />
<br />
#!/bin/bash<br />
echo "hello, world" > /tmp/eraseme.txt<br />
echo "invocation: $@"<br />
echo<br />
echo "$1:"<br />
cat "$1"<br />
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - -"<br />
env<br />
<br />
It appears that no environment variables are being set. The first (and only) argument is the location of a file in /tmp that contains the Inkscape SVG data.<br />
<br />
'''Now what?'''<br />
<br />
The strategy is this:<br />
<br />
* create a directory, representing the wiki<br />
* place a file in the directory, "oddmuse.txt", representing necessary details about the wiki<br />
* when the user saves a file to the directory (.odd extension,) do the following:<br />
** push the SVG to the wiki<br />
** render a PNG, and push the PNG to the wiki<br />
** perhaps append the name of the wikipage containing the SVG to a page on the wiki<br />
<br />
We don't have command-line access (bash argument, environment variable) to the filename or<br />
directory it was saved in. But we CAN get this data from the Inkscape SVG.<br />
<br />
The <svg> element has attributes:<br />
* "sodipodi:docbase" -- path up to the save location<br />
* "sodpodi:docname" -- filaname, including extension (".odd", in this case)<br />
<br />
<br />
== Inkscape Export process ==<br />
<br />
* User hits "Save" in "Save As" dialog<br />
* Inkscape writes a file with a random name to /tmp<br />
* Inkscape calls export bash script, with /tmp file as only argument<br />
* Whatever bash outputs to /dev/stdout, Inkscape records to the file chosen by the user.</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiExporter&diff=5562WikiExporter2005-02-12T21:03:04Z<p>LionKimbro: * getting path and filename from Inkscape SVG</p>
<hr />
<div>These are LionKimbro's notes on developing a wiki exporter.<br />
<br />
Date: 2004-02-12<br />
Inkscape version: 0.40<br />
Target: Oddmuse<br />
<br />
That is, a system so that you can load from and save to a wiki.<br />
<br />
The wiki targetted by this exporter is Oddmuse. We have [http://www.oddmuse.org/cgi-bin/oddmuse/Automatic_Posting_and_Uploading#wikiupload an upload script for it.]<br />
<br />
I imagine it should be possible to use the Wiki XML-RPC interfaces as well, in the future, though they are usually turned off.<br />
<br />
'''odd_output.inx'''<br />
<br />
This file goes in: /usr/share/inkscape/extensions<br />
<br />
<inkscape-extension><br />
<name>Oddwiki Output</name><br />
<id>org.inkscape.output.odd</id><br />
<dependency type="executable" location="extensions">svg2oddmuse.sh</dependency><br />
<output><br />
<extension>.odd</extension><br />
<mimetype>image/x-svgz</mimetype><br />
<filetypename>Oddmuse Wiki POST (*.odd)</filetypename><br />
<filetypetooltip>Oddmuse Wiki proxy (SVG, PNG of Drawing)</filetypetooltip><br />
<dataloss>FALSE</dataloss><br />
</output><br />
<script><br />
<command reldir="extensions">svg2oddmuse.sh</command><br />
<helper_extension>org.inkscape.output.svg.inkscape</helper_extension><br />
</script><br />
</inkscape-extension><br />
<br />
'''What data am I receiving from Inkscape?'''<br />
<br />
To see what you're getting from Inkscape, create the following script, and call it: '''svg2oddmuse.sh'''<br />
<br />
#!/bin/bash<br />
echo "hello, world" > /tmp/eraseme.txt<br />
echo "invocation: $@"<br />
echo<br />
echo "$1:"<br />
cat "$1"<br />
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - -"<br />
env<br />
<br />
It appears that no environment variables are being set. The first (and only) argument is the location of a file in /tmp that contains the Inkscape SVG data.<br />
<br />
'''Now what?'''<br />
<br />
The strategy is this:<br />
<br />
* create a directory, representing the wiki<br />
* place a file in the directory, "oddmuse.txt", representing necessary details about the wiki<br />
* when the user saves a file to the directory (.odd extension,) do the following:<br />
** push the SVG to the wiki<br />
** render a PNG, and push the PNG to the wiki<br />
** perhaps append the name of the wikipage containing the SVG to a page on the wiki<br />
<br />
We don't have command-line access (bash argument, environment variable) to the filename or<br />
directory it was saved in. But we CAN get this data from the Inkscape SVG.<br />
<br />
The document has attributes:<br />
* "sodipodi:docbase" -- path up to the save location<br />
* "sodpodi:docname" -- filaname, including extension (".odd", in this case)<br />
<br />
<br />
== Inkscape Export process ==<br />
<br />
* User hits "Save" in "Save As" dialog<br />
* Inkscape writes a file with a random name to /tmp<br />
* Inkscape calls export bash script, with /tmp file as only argument<br />
* Whatever bash outputs to /dev/stdout, Inkscape records to the file chosen by the user.</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WhiteboardSeniorProjectProposal&diff=5514WhiteboardSeniorProjectProposal2004-05-10T20:26:45Z<p>LionKimbro: * signed</p>
<hr />
<div>Many times a picture can describe ideas that are impossible over simple text based communication (chat). With many work teams having physically diverse locations sometimes sharing and working on pictures can be very difficult. This project is to create a real-time online whiteboarding application using instant messaging protocols. The problems with previous projects of this type is that they use very simplified drawing models that restrict the user or they use a specially designed protocol that requires special set up. This project aims to remove both of those restrictions by using standards, and an existing vector drawing application.<br />
<br />
This project involves extending a current vector drawing program (Inkscape) using the standard XMPP messaging protocol (Jabber). Inkscape is based on the W3C's XML based vector graphics format SVG. Internally, Inkscape maintains the structure of this document, and has events occur when this model is changed by the user. When this occurs, a message can be sent to another instance of Inkscape monitoring an XMPP stream on another host, perhaps in another country.<br />
<br />
This project would involve learning the Inkscape architecture, SVG and XMPP standard and then extending them to achieve the required functionality. Depending on the team size, group chat should also be supported.<br />
<br />
----<br />
<br />
Hi, Ted! My name is LionKimbro. Good to meet you! :)<br />
<br />
We've made a primitive, but already useful, text whiteboarding app [http://intcomm.wiki.taoriver.net/moin.cgi/SubPathetaEdit over at IntComm.] We use it regularly in our IRC, now, particularly while development.<br />
<br />
(You can [http://intcomm.wiki.taoriver.net/moin.cgi/2004_2d5_2d9 see our cheezy ASCII drawings,] made during our IRC meetings.)<br />
<br />
Obviously, we need an SVG whiteboard editor. We've had our eyes on Inkscape for a while now, because the project devs appear to be sympathetic to the idea of whiteboarding.<br />
<br />
I know that I myself, [http://intcomm.wiki.taoriver.net/moin.cgi/LionKimbro (LionKimbro,)] [http://intcomm.wiki.taoriver.net/moin.cgi/JonathanRoes JonathanRoes,] and perhaps Evan Podramou, would be excited to work on a whiteboard project.<br />
<br />
I would think though, that the ''easiest'' thing to do, immediately, is to do ''exactly'' what we did in our text communications system: Just throw the entire SVG file over the network, once every 3 seconds.<br />
<br />
Have an XML-RPC doc server. It can ''even'' be the ''exact'' same document server we are using right now, with [http://intcomm.wiki.taoriver.net/moin.cgi/SubPathetaEdit IntComm:SubPathetaEdit.]<br />
<br />
Then make periodic 3 second "GET" requests to the document server.<br />
<br />
In the event that you ''did'' something, perform a POST.<br />
<br />
Yes, I know: It's ''gross.'' But: It works! Even with large documents.<br />
<br />
''Then,'' after you get this very simple and cheezy system done, you can get more elaborate. And you have the help of a whiteboard as you develop your new system!<br />
<br />
You're invited to talk with us over in irc.freenode.net #onebigsoup -<br />
<br />
I would be surprised if we couldn't get this working within 3 days, after we are able to build Inkscape, and an XML-RPC library.<br />
<br />
Basically, we just need to make it Load or a Save automatically every three seconds.<br />
<br />
-- LionKimbro</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WhiteboardSeniorProjectProposal&diff=5513WhiteboardSeniorProjectProposal2004-05-10T20:26:24Z<p>LionKimbro: * How to make a gross but basic whiteboarding system in 3 days.</p>
<hr />
<div>Many times a picture can describe ideas that are impossible over simple text based communication (chat). With many work teams having physically diverse locations sometimes sharing and working on pictures can be very difficult. This project is to create a real-time online whiteboarding application using instant messaging protocols. The problems with previous projects of this type is that they use very simplified drawing models that restrict the user or they use a specially designed protocol that requires special set up. This project aims to remove both of those restrictions by using standards, and an existing vector drawing application.<br />
<br />
This project involves extending a current vector drawing program (Inkscape) using the standard XMPP messaging protocol (Jabber). Inkscape is based on the W3C's XML based vector graphics format SVG. Internally, Inkscape maintains the structure of this document, and has events occur when this model is changed by the user. When this occurs, a message can be sent to another instance of Inkscape monitoring an XMPP stream on another host, perhaps in another country.<br />
<br />
This project would involve learning the Inkscape architecture, SVG and XMPP standard and then extending them to achieve the required functionality. Depending on the team size, group chat should also be supported.<br />
<br />
----<br />
<br />
Hi, Ted! My name is LionKimbro. Good to meet you! :)<br />
<br />
We've made a primitive, but already useful, text whiteboarding app [http://intcomm.wiki.taoriver.net/moin.cgi/SubPathetaEdit over at IntComm.] We use it regularly in our IRC, now, particularly while development.<br />
<br />
(You can [http://intcomm.wiki.taoriver.net/moin.cgi/2004_2d5_2d9 see our cheezy ASCII drawings,] made during our IRC meetings.)<br />
<br />
Obviously, we need an SVG whiteboard editor. We've had our eyes on Inkscape for a while now, because the project devs appear to be sympathetic to the idea of whiteboarding.<br />
<br />
I know that I myself, [http://intcomm.wiki.taoriver.net/moin.cgi/LionKimbro (LionKimbro,)] [http://intcomm.wiki.taoriver.net/moin.cgi/JonathanRoes JonathanRoes,] and perhaps Evan Podramou, would be excited to work on a whiteboard project.<br />
<br />
I would think though, that the ''easiest'' thing to do, immediately, is to do ''exactly'' what we did in our text communications system: Just throw the entire SVG file over the network, once every 3 seconds.<br />
<br />
Have an XML-RPC doc server. It can ''even'' be the ''exact'' same document server we are using right now, with [http://intcomm.wiki.taoriver.net/moin.cgi/SubPathetaEdit IntComm:SubPathetaEdit.]<br />
<br />
Then make periodic 3 second "GET" requests to the document server.<br />
<br />
In the event that you ''did'' something, perform a POST.<br />
<br />
Yes, I know: It's ''gross.'' But: It works! Even with large documents.<br />
<br />
''Then,'' after you get this very simple and cheezy system done, you can get more elaborate. And you have the help of a whiteboard as you develop your new system!<br />
<br />
You're invited to talk with us over in irc.freenode.net #onebigsoup -<br />
<br />
I would be surprised if we couldn't get this working within 3 days, after we are able to build Inkscape, and an XML-RPC library.<br />
<br />
Basically, we just need to make it Load or a Save automatically every three seconds.</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiNode&diff=5616WikiNode2004-05-04T19:39:00Z<p>LionKimbro: *</p>
<hr />
<div>Welcome to the [[Inkscape]] wiki!<br />
<br />
'''Key Points of Interest:'''<br />
<br />
(what should go here?)<br />
<br />
'''Neighboring Wiki:'''<br />
<br />
* [http://www.protocol7.com/svg-wiki/ow.asp?WikiNode SVG wiki]<br />
* [http://freedesktop.org/Software/clipart Open Clip Art Project] - (no Wiki''''''Node yet)<br />
* [http://visual.wiki.taoriver.net/moin.cgi/WikiNode Visual] - visual language</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiNode&diff=5615WikiNode2004-05-04T19:38:48Z<p>LionKimbro: * +SVG wiki</p>
<hr />
<div>Welcome to the [[Inkscape]] wiki!<br />
<br />
'''Key Points of Interest:'''<br />
<br />
(what should go here?)<br />
<br />
'''Neighboring Wiki:'''<br />
<br />
* http://www.protocol7.com/svg-wiki/ow.asp?WikiNode SVG wiki]<br />
* [http://freedesktop.org/Software/clipart Open Clip Art Project] - (no Wiki''''''Node yet)<br />
* [http://visual.wiki.taoriver.net/moin.cgi/WikiNode Visual] - visual language</div>LionKimbrohttps://wiki.inkscape.org/wiki/index.php?title=WikiNode&diff=5614WikiNode2004-05-04T19:37:03Z<p>LionKimbro: Initial WikiNode entry</p>
<hr />
<div>Welcome to the [[Inkscape]] wiki!<br />
<br />
'''Key Points of Interest:'''<br />
<br />
(what should go here?)<br />
<br />
'''Neighboring Wiki:'''<br />
<br />
* [http://freedesktop.org/Software/clipart Open Clip Art Project] - (no Wiki''''''Node yet)<br />
* [http://visual.wiki.taoriver.net/moin.cgi/WikiNode Visual] - visual language</div>LionKimbro