Difference between revisions of "User:Tsingi"

From Inkscape Wiki
Jump to navigation Jump to search
Line 3: Line 3:
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]
* islint at [http://islint.sourceforge.net/ SourceForge]
* islint at [http://islint.sourceforge.net/ SourceForge]
* [http://wiki.inkscape.org/wiki/index.php/Islint islint requirements] note on this wiki


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.
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.
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 [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG 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 first two points, process Beziers how?  Collapse transforms how?
* '''''Process quadratic Bezier curves'''''
* '''''Collapse all group based transformations'''''
* '''''Convert known properties to element attributes'''''
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/User:Tsingi#Clean_up_CSS Clean up CSS]'' above.
* '''''css to element attributes'''''
see ''[http://wiki.inkscape.org/wiki/index.php/User:Tsingi#Clean_up_CSS Clean up CSS]'' above.
=== 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.

Revision as of 12:35, 24 September 2009

I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.

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.

Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&oldid=53877"