Difference between revisions of "Islint-implementation"

From Inkscape Wiki
Jump to navigation Jump to search
(Created page with '== 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...')
 
Line 1: Line 1:
linked from [http://wiki.inkscape.org/wiki/index.php/Islint islint]
== Wiki Notes Annotated ==
== Wiki Notes Annotated ==



Revision as of 14:37, 27 September 2009

linked from 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 v0.8. 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 v0.8.

  • 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 v0.8. 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 v0.8 (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 Clean up CSS above.

  • css to element attributes

see Clean up CSS above.

Output Standard SVG

DONE v0.8. 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. Currently only possible via the command line interface.

  • 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.

Implementation Notes

I'll keep track of what I do, am doing here. v0.8 is the version as of this writing.

CSS Styling v0.8

Currently islint either creates inline CSS style sheets, or leaves styling alone. Only style attributes are processed.

  • TODO:
    • parse XML style attributes (stroke=, fill=)
    • implement options for document styling:
      • CSS (inline or external)
      • style attributes
      • standalone XML attributes


--Tsingi 12:29, 24 September 2009 (UTC)