Difference between revisions of "User:Tsingi"
Line 47: | Line 47: | ||
Not sure what is meant here. | Not sure what is meant here. | ||
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format''''' | * '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format''''' | ||
''Not done, easy, med priority''. | ''Not done, easy, med priority''. | ||
''DONE'' I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them. | |||
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them. | |||
* '''''Convert RGB colours from #RRGGBB to #RGB if possible''''' | * '''''Convert RGB colours from #RRGGBB to #RGB if possible''''' | ||
''Not done, easy, med priority''. | ''Not done, easy, med priority''. | ||
=== Clean up paths === | === Clean up paths === | ||
''DONE'' (my way) What isn't mentioned here, and is fully implemented in islint, is recovering, circles, ellipses, lines, polylines and polygons. islint parses 'd' attributes into path segments, analyzes them, converts if possible, else puts them back together being very stingy with white space. A large effort was put forth here, so the code is in good shape for further reduction operations on paths. The sodipodi namespace data makes it possible to recover circles and arcs. | ''DONE'' (my way) What isn't mentioned here, and is fully implemented in islint, is recovering, circles, ellipses, lines, polylines and polygons. islint parses 'd' attributes into path segments, analyzes them, converts if possible, else puts them back together being very stingy with white space. A large effort was put forth here, so the code is in good shape for further reduction operations on paths. The sodipodi namespace data makes it possible to recover circles and arcs. |
Revision as of 11:53, 24 September 2009
I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.
- Wiki profiler page: Save_Cleaned_SVG
- islint at SourceForge
My motives are purely selfish. I'm one of the authors of SVG, I work with SVG, and I find InkScape to be an excellent tool, but I spend a lot of time editing InkScape output with vi to clean it up for use in dynamic web apps (mostly). A task with very low entertainment value. Writing filters is more fun.
islint is pretty useful to me as is now, it has a way to go before it will serve as a general filter for InkScape.
notes on islint
This is the wrong place to do this, but it will serve for now...
islint
Wiki Notes Annotated
I don't agree with some of the assumptions in these notes. I suspect that that's because I have different use cases for SVG than the person who wrote them. Sometimes it's hard to be objective in these matters. It would be good to have developers from different disciplines take a look at this list in order to get a useful generic set of requirements.
In italics is a copy of the Cleaning Operations list from the Save_Cleaned_SVG page
Notes are formatted like this. Status, difficulty, priority like this.
Specify a limit to the precision of all positional elements.
DONE. Trimming precision was my first priority. precision can be set to -1 (off) or 0..9. islint gives an extra decimal to transformation floats, so if you set prec=1, a matrix will have values to two decimal places. This is to preserve a little sanity at a low cost should there be nested transforms.
Clean up XML Elements
- Collapse multiple redundant groups
Not done, easy, low priority.
- Remove empty tags, such as defs or metadata.
Not done, easy, low priority.
- Remove id tags for elements not referenced
Not done, easy, low priority. I like to have an id on everything. I usually want something more useful than path1234, but that requires either human intervention, or a targeted generator. I can add it as an option.
Clean up Definitions
Not done, moderate, low priority. Generally I think this section needs a bit of work. I don't use InkScape for gradients much, but I could. InkScape creates a lot of gradients and creates and references linear gradients when it needs a radial gradient. It is possible to do a lot of cleanup here.
- Remove unused definitions
- Remove duplicate gradient stops
- Collapse duplicate gradient definitions
- Remove gradients that are only referenced by one other gradient
Clean up CSS
islint implements inline CSS style sheets by parsing the style attributes (style=) into a table removing defaults, merging them, substituting class attributes, and finally, creating an inline style sheet. At the moment it does nothing with standalone XML attributes (stroke=, fill=) Currently I do not READ CSS tables or files for updating. This is a HIGH PRIORITY I like to use external CSS, it makes projects easy to adapt. If I can read in inline style sheets or external css files, I can carry along a naming convention in the style sheet. I need to know more about the InkScape plugin interface before I can implement separate CSS files. Perhaps a two stage operation? 1. profile the document, 2, save and reference the style sheet?
- So, I have implemented one method of styling, possibly the most difficult one. Certainly the one I find most useful. This is done in the first pass of the document, gathering up all the styling. Writing the styling is done dead last, after all other manipulations have completed.
- It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.
- Remove Default values, i.e. opacity: 1;
DONE.
- Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;
Not sure what is meant here.
- Convert RGB colours from RGB(r,g,b) to #RRGGBB format
Not done, easy, med priority.
DONE. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.
- Convert RGB colours from #RRGGBB to #RGB if possible
Not done, easy, med priority.
Clean up paths
DONE (my way) What isn't mentioned here, and is fully implemented in islint, is recovering, circles, ellipses, lines, polylines and polygons. islint parses 'd' attributes into path segments, analyzes them, converts if possible, else puts them back together being very stingy with white space. A large effort was put forth here, so the code is in good shape for further reduction operations on paths. The sodipodi namespace data makes it possible to recover circles and arcs.
- Detect vertical/horizontal lines and replace.
Not done, easy, high priority.
- Eliminate empty path segments
Not done, easy, high priority. I didn't know there were any.
- Eliminate last segment in a polygon
Not done, easy, high priority.
- Collapse straight curves.
Not done, ???, med priority.
- Convert absolute path segments to relative ones.
Not done, easy, high priority.
Process Transformations
Do not understand these points, process Beziers how? Collapse transforms how?
- Process quadratic Bezier curves
- Collapse all group based transformations
- Convert known properties to element attributes
- css to element attributes
Output Standard SVG
DONE. islint removes all namespaces it has not been told to keep. It is possible to tell it to preserve foreign namespaces by adding them through an option.
- Remove inkscape namespace
- Remove sodipodi namespace
- Remove adobe namespace
- Use viewPort instead of document width/height
Not done, difficult, medium priority. There many many ways to specify the document extent in SVG. Some analysis needs to be done before attempting to automate this.