Difference between revisions of "ImprovingPythonEffectsAPI"
Line 39: | Line 39: | ||
===AutoShapes extensions=== | ===AutoShapes extensions=== | ||
Each AutoShape would generate a different figures given particular parameters from a GUI (like the star tool, but not being objects in Inkscape) | Each AutoShape would generate a different figures given particular parameters from a GUI (like the star tool, but not being objects in Inkscape). Unlike AutoShapes in most drawing programs, which can only be scaled, many parameters of these AutoShapes could be configured (like the Lindenmayer). To implement some of these, I might need to improve how the GUI interfaces with the effects (i.e. to collect a list of numbers of varying size as in unit subdivision). | ||
* circle unit subdivision algorithm *#* | Some examples | ||
* circle unit subdivision algorithm (see an example here) *#* | |||
* Cartesian and Poler graph with unit subdivision | * Cartesian and Poler graph with unit subdivision | ||
* Ruler dashes with unit subdivision | * Ruler dashes with unit subdivision |
Revision as of 21:43, 29 April 2006
Introduction
For a year now, I have been writing python scripts to generate and manipulate SVG. My motivations in doing so was to allow me to plot complex geometrically defined patterns in a precise way. When I searched over the internet for code that could do this, I didn't find what I needed. Math plotting libraries like GNUplot were not what I was looking for. I learned about ActionScript for Flash, but I didn't want to get locked into a proprietary standard. I also learned a bit about Javascript and the use of it to modify the DOM in SVG, but I wasn't liking JavaScript for generating SVG. Nor was I impressed with the code on a website called "Programmer Art" (which has since gone defunct) or the very basic examples on ASPN.
I wanted a simpler way of creating elements so that I didn't have to write a setAttribute line for every attribute as in JavaScript; instead I wanted to be able to call a construtor/method in order to add elements (allowing for default values of attributes, style libraries, etc.), using the simplicity and power of Object-Oriented Programming in Python to abstract SVG images in a clearer way. One of the first things I accomplished was to make the DOM tree easily accessible though the use of Amara. This made all attributes represented as a dictionary (which I later found out overlaped the work done in the extension tutorial) and the elements of the tree were easily traversed in a "pythonic" way.
Though these scripts can not run in server-side web browsers like JavaScript can, they were not designed to do so; instead they were designed to be a library of functions that generate complex SVG shapes. Some of these scripts may draw thousands of lines, and so it would be inefficient to generate the image every time it is viewed on a web page. Instead the script runs once and outputs an .svg file.
I was particularly interested in creating mandala-like patterns with my code, so I needed an easy way to convert polar co-ordinates to cartesian ones. I looked for a simple 2D geometry library in python but found nothing which suited the task, so I created one for the purpose of representing points as objects that could be manipulated by different algorithms and formulas.
Over the last year my imagination has discovered a richness of geometric/design problems to solve. In my proposal, I have listed a number of features/algorithms that I have already implemented in my stand-alone SVG applications. I have marked these with a "*#*".
Proposal
My goals in working on the python extensions would be to improve the Python plugin API
Mathematical libraries for plotting points
- Cartesian and Polar points with conversion to and from each other. Operations such as addition, subtraction, dot product, scalar multiplication *#*
- Midpoint of two points *#*
- Point at a fraction of a distance from point A to point B *#*
- pointsBetween - given A and B, returns n equidistant points along the line *#*
- extendBend - given two points A and B, a distance and an angle, returns a point C which results from extending distance out from AB and then bending BC about B by the given angle *#*
- reflection - given a line AB and point C, returns the reflection of C in AB #*
Functions for manipulating paths
- abstractions for each path command and random access to the list of commands (so you can look backward and see what point the inspected command is starting from) *#*
- path distance calculation *#*
- convert a quadradic bezier into a cubic bezier *#* figured out this one purely by experimentation
- each Command object (i.e. one of class CubicBezierCommand) stores control points and nodes as Point objects *#*
- return an array of references to all Points in the path (which could then be operated on by some function or other operation) *#*
- create a closed symetrical path out of an open path that is one side of the shape by appending it's mirror (along the start-end line) to itself
- develop new ways of constructing and representing bezier curves relative to their start and end points i.e. where the control points are represented as a vector relative to the base line of the curve *#*
- functions to return points a certain distance along a path, or a certain percentage of the distance of the path
- functions to do complex path slicing/merging where the number of commands is increasing or decreasing
- obtain a point a certain distance along a path
- add texture to curves
- similar to Kochify but that only applies 1 copy in between nodes wheras this would apply a pattern many times along one line or bezier command
- an example application: given a leaf outline, give a jagged texture of it
AutoShapes extensions
Each AutoShape would generate a different figures given particular parameters from a GUI (like the star tool, but not being objects in Inkscape). Unlike AutoShapes in most drawing programs, which can only be scaled, many parameters of these AutoShapes could be configured (like the Lindenmayer). To implement some of these, I might need to improve how the GUI interfaces with the effects (i.e. to collect a list of numbers of varying size as in unit subdivision). Some examples
- circle unit subdivision algorithm (see an example here) *#*
- Cartesian and Poler graph with unit subdivision
- Ruler dashes with unit subdivision
- "star polygon" creation along with creation of a dictionary of all "proper" poygon stars (see this page on [ http://mathworld.wolfram.com/StarPolygon.html Stars Polygons ] ) *#*
- hexagon grid *#*
- flower-like radial shapes *#* done some, but there's many possibilities
- series of circles forming a Cartoid *#*
- generation of phi spiral and phi spiral lattice (think dreamcatcher pattern) *#* (but after much contemplation/experimentation I haven't figured out how to get my spiral curves smoother)
- zig zag and loop-de-loop line generation *#*
I have added some screen shots of the SVG IMAGENERATION on my new Flickr account (silly to rasterize SVG, but I haven't found good SVG gallery service/software, hope openclipart.org get ccHost working soon)
Selling Self and Proposal
I'm a fourth year Computer Science student at Carleton University. I've yet to have a paid job as a programmer, but I've done a bunch technology-related volunteering and a lot of self-education to suppliment my university education. I believe I'm an excellent candidate for this position because I:
- use Inkscape regularly and am familiar with all its features
- have the (electronic) book Learn SVG as a reference
- have a bunch of code already written which could be applied to the project
- will pour a lot of my energies into this project during the summer, during which I do not have other labour commitments
- enjoy writing and will provide good documentation for both developers and end users
- will continue to improve Inkscape beyond the term of my work
- am aligned with the values of the Free Software movement and its offshoots like Creative Commons and Free Culture community (this year I started organizing Free Culture Carleton)
My proposal will be a significant improvement to Inkscape because:
- effects are a strong driving force between many different media applications (i.e. raster graphics, audio, video, 3D) and extend the capabilities of them greatly
- there are many unimplimented effects that could be easily developed, as there's a lot of publications about computer graphics geometry describing the theoretical process
- despite this, there has not been a strong community of development around effects in Inkscape
- improving the ease of development and documentation around effects will encourage developers to create new effects
- python is an extremely accessible language that proves itself ideal for effects scripting (i.e. Blender scripting)
- improving python effects libraries would expand functionality of Inkscape without introducing any bugs to the core C++ code
- improving python effects may offer ideas/sketches to improve path data structures internally
Any feedback on this proposal would be greatly appreciated
Thanks,
Justin touchmewithsynchronicpulses)aat(gmail.com