https://wiki.inkscape.org/wiki/api.php?action=feedcontributions&user=Tsingi&feedformat=atomInkscape Wiki - User contributions [en]2024-03-28T23:25:57ZUser contributionsMediaWiki 1.36.1https://wiki.inkscape.org/wiki/index.php?title=FeatureNotePad&diff=61903FeatureNotePad2010-05-07T17:46:13Z<p>Tsingi: /* Minor Grid Improvements */</p>
<hr />
<div>Here is a notepad for quickly noting down good ideas (newest first please). If you're bored, feel free to write these as full feature requests and add to the tracker, or as separate Wiki pages.<br />
<br />
[[FeatureNotePadArchive]] (dupes, already implemented ideas, those with acceptable workarounds, those that cannot be implemented at all)<br />
<br />
Note: there is also a bug/feature request tracker at [http://sourceforge.net/tracker/?group_id=93438&atid=604309 sourceforge.net].<br />
<br />
== Continuous race with constant width ==<br />
The "trace bitmap" tool is very useful, but when the bitmap quality is too low, it often creates un-continuous drawing. A nice improvement would be to force the tool to draw continuous paths, and another nice one would be to make it keep a constant width. <br />
<br />
It would be useful "tracing" many things, and particularly maps --[[User:Pethrus|Pethrus]] 15:48, 3 April 2010 (UTC) <br />
<br />
== Rotate Everything ==<br />
<br />
Often I find myself needing to know how my image would look were it rotated sideways or upside down. It would be nice if there was an easy and quick method of rotating everything in all layers (or just the whole viewport of the Inkscape window itself).<br />
<br />
== Layer Clip and Mask ==<br />
<br />
Allow clips and masks to work on entire layers. Adobe Illustrator has a similar feature that's described and demonstrated in the third page of [http://mos.futurenet.com/pdf/computerarts/ART157_tut_illus.pdf this tutorial] (see points 7 and 8).<br />
<br />
== Non Editable Linked Offset ==<br />
<br />
If we could have an special "non editable Linked Offset" (working title), effect developers could have an powerful tool for creating various effects that involve "copies" of a parent shape or path (like dropshadows, inner shadows, illumination, randomized copies, etc.)<br />
<br />
It would behave the same as an un-scaled linked offset, but it would have to also follow the rotation and tearing of parent shape, and the user could not edit its position, shape or scale through the canvas directly (it would not show position markers, and it would not respond to selection). It could only be altered by changing the parent shape, or by an specified effect settings GUI.<br />
<br />
This way effect developers can create multiple options that would be free of the risk of the user accidentally changing the scale of the linked offset, resulting in undesired behavior of the effect position.<br />
<br />
Also, I think that this method would facilitate the "stacking" of various effects around one shape.<br />
<br />
Effects created this way could be grouped under their own effects menu subgroup, and would have the great advantage of working the same for paths and predefined shapes (ellipse, star, polygon, rectangle) without having to convert to path first, so they don't lose their special shape handlers ( corner radius, star angle, etc.). This way the shape remains editable and the effects aplied follow accordingly.<br />
<br />
[[User:Sinuhe|Sinuhe]] 19:16, 23 March (UTC)<br />
<br />
== Enhanced Mirror Symmetry ==<br />
<br />
When drawing complex shapes it is often useful to have the left and the right side of the shape look the same. The Mirror Symmetry live path effect does this very nicely, but unfortunately there is no way to *join* the mirrored shape with the original one. The two shapes would have to be sub-pixel perfectly aligned in order to avoid tearing.<br />
<br />
So basically there would be an option called "do clipping"(name borrowed from the Blender Mirror Modifier) which when selected makes the mirror modifiers delete all the stuff on a certain side of the mirror line(which side *should* be an option too), makes new nodes where the shape was cut, and connects those nodes with the nodes of the mirrored shape. This way you get ONE path with no seam lines between the mirrored pieces.<br />
<br />
[[User:Agony|Agony]] 14:23, 14 December 2008 (UTC)<br />
<br />
== Minor Grid Improvements ==<br />
<br />
Would be handy to have a way for the origin of the grid be the centre of the page, vertically/horizontally/both, or maybe even a percentage, rather than having to calculate where that might be. Also, a feature I've used a lot in [http://bourbon.usc.edu/tgif/ tgif] is the ability to quickly halve or double the grid size. In tgif it's done by left or right click on the ruler. Lastly, some feedback would be good to show how close an object currently is to the grid, but I've not thought hard about how that might be displayed.<br />
<br />
--[[User:Daeghnao|Daeghnao]] 11:07, 16 August 2007 (UTC)<br />
<br />
== Radial Grid ==<br />
<br />
A radial grid would be really handy. I've created these on occasion.<br />
<br />
You should be able to set the center point.<br />
<br />
--[[User:Tsingi|Tsingi]] 17:46, 7 May 2010 (UTC)<br />
<br />
== Gradient Fills ==<br />
Conical (or 'angle') gradient fills would be most useful.<br />
<br />
[[Image:conical.png]]<br />
<br />
== Fill Gallery ==<br />
A default fill gallery.<br />
<br />
When I want to build an area with a nicely complex multicolored fill of some sort, I don't want to have to build the fill from scratch every time. I want a huge array of default fills to start with, which I can modify to my heart's content using the existing fill editor.<BR><br />
[[User:Jonathanbrickman0000|Jonathanbrickman0000]] 17:06, 3 January 2007 (UTC)<br />
<br />
:: Extend this Idea to a Stylesheet-Sidebar, where the User can easily drag&drop already used styles to objects. I think on something like Microsoft word does when a user is formatting a text-fragment in a new way: the new formatting is shown in the Formating-Sidebar. [[User:MovGP0|MovGP0]] 19:57, 6 May 2007 (UTC)<br />
<br />
== EPS Export ==<br />
A modified version of the eps export.<br />
<br />
I m currently working with maya and I can't import eps from inkscape.<br />
Except if i modified the text manualy. I need to replace moveto by <br />
m and curveto by c. I also need to put my vector in the top right corner.And once import to flip verticaly the line. <br />
So if there was an option to record a modified eps I think people making 3d will be really happy.<br />
<br />
== openclipart.org Export ==<br />
An easy way to submit clipart to openclipart.org. Currently you have to save a clipart to a file, open a web browser, login to openclipart.org and browse for the previously saved file in order to upload... A "submit selection to openclipart.org" menu entry would be handy, it would remember login and prompt for a cliparts' meta information before upload... Perhaps such functionality should be a plugin...<br />
<br />
:I think there should be rather a API that allows write a Plugin doing so, because <br />
:*there are more Websites that are an interesting target like Wikipedia's Commons, Flickr (supporting only PNG/JPG-Export instead of SVG), and many others<br />
:*openclipart.org is unreachable while I'm writing this and I'm not sure if the Website is still existing at all. Websites can happen to go offline, so its not wise to code for single distributors. <br />
:[[User:MovGP0|MovGP0]] 20:14, 6 May 2007 (UTC)<br />
<br />
== Arbitrary Zoom ==<br />
Arbitrary precision zoom levels:<br />
<br />
-Unlimited scaling on zoom would be a very useful feature in some applications, allowing for unlimited detail.<br />
<br />
== Rotation ==<br />
Persistent rotation centers TODO: <br />
<br />
* make it work smartly for groups: if a group has center not set, return the center of the first object inside group with the center set<br />
* a separate tab in the Transform dialog, with 9 buttons in the square grid (for setting it to object's corners, sides, and center) as well as x/y fields for setting center to any position<br />
<br />
== Plain SVG Export ==<br />
''wwwwolf writeth:''<br />
<br />
An XSL stylesheet to convert from [[InkscapeSVG]] to [[PlainSVG]]<br />
<br />
If we had that, it wouldn't be necessary to use Inkscape's exporter in all situations - it could be used to make plain SVG without user intervention, automatically, and in places where Inkscape isn't even installed - all you need is an XSLT processor. This would be highly cool since some of the programs (I'm looking at YOU, Scribus *and* rsvg) at times choke randomly on Inkscape markup but render Inkscape's plain SVG without problems.<br />
<br />
== Extended Stroke Rendering ==<br />
Extend stroke rendering capabilities<br />
<br />
Make it possible for the definition of the rendering of a stroke to be scriptable (at stroke time). For instance, I might want to render a path as a series of flames - the size of the flames somewhat randomized, perhaps, along the stroke. Because they are flames, my script would make sure they're always pointing the same direction (up) along the stroke. Similarly, a series of water droplets would always be rendered dripping in a downward direction.<br />
<br />
Note that much of this functionality could also be done outside of scripting, using an approach similar to tiled clones.<br />
<br />
== Edge-Offsets ==<br />
<B>kwixson writes:</B><br />
<br />
* Edge offsets in flowed text with automatically drawn linked offsets of the object with no fill or stroke properties.<br />
* Visual cue for selected groups (i.e., solid marquee instead of dashed)<br />
* Undo in draw mode removes last node, not the entire path, same as backspace key<br />
* Set the ruler 0, 0 coordinates by dragging a cross out of the rulers' corner / double click to set precisely, according to 0,0 index of page dimensions.<br />
* Make space bar held down transform cursor to Selector tool until spacebar is released, with any tool except Text.<br />
<br />
== Smooth drawings ==<br />
<br />
2.) Sub-pixel resolution in drawing, is possible with XInput i think?<br />
- Again, improves drawing by hand<br />
3.) Smooth drawing, smooth over small irrelegularities from mouse/drawing board<br />
- Same as all of the above, improves drawing, makes it a whole lot more fun! :)<br />
<br />
It doesn't seem so hard to implement but it would make a huge diffrence!<br />
<br />
Aside from that, I love where Inkscape is going, the interface is great to work with and it just keeps getting better!<br />
I find myself building from CVS so I dont't miss out.<br />
<br />
GREAT WORK GUYS! :)<br />
<br />
== Extrusion and Shadows ==<br />
<B>Ilja writes:</B><br />
<br />
1.) Extrusion of Objects<br />
2.) Dropshadow, kind of a clone - a bit fuzzy and little shifted behind<br />
<br />
<B>Sinuhe Writes: </B><br />
<br />
I'd like to see these in Inkscape, they are very common effects and I would like to see a faster way to achieve them than the current methods (copy object, relocate it, change color, change blur, change alpha).<br />
<br />
The current 3D Border effect works only with paths, not objects, wich is not very useful if you want to later modify the form (you lose the special modyfiers for stars, corner radius on rectangles, etc.) I would also like to see a way to change the color of the shadow created.<br />
<br />
Currently the best way to get a drop shadow or inner shadow is with a linked offset, so this "new effect" could just be an automatic sequence for creating the linked offset and change its color, alpha, position and blur to user-specified params. The linked offset works with objects as with paths so its just perfect and no need to convert to path. The main problem I see with this technique is that if you accidentally modify the linked offset scale, it won't follow the parent shape in the same precise way, but in a relative position to where it was first placed.<br />
<br />
With a similar tool, we could achieve an "Ilumination Effect" (similar to that in Freehand) by creating a linked offset, erasing fill, changing outline color, rising outline width and blurring it(It would have the same issue with accidentally modifying linked offset).<br />
<br />
Maybe we need an special object that is like a linked offset but is not directly editable or selectable? It would speed the creation of many different effects that would work in objects as in paths.<br />
<br />
== Some small Features ==<br />
<b>Daddio writes:</b><br /><br />
A couple of Small features that would help those of us a <b>lot</b> that like to draw a basic shape and then tweak it in the xml editor:<br /><br />
1) the ablility to convert the SVG coordinates in a path to <i>and from</i>relative coordinates (small case m's l's c's a's) except perhaps the initial M<br /><br />
2) the ability to truncate <i>(or even better, round)</i> the SVG coordinates to 1, 2 or zero (etc) decimal places.<br /><br />
3) Set a decimal place limit so the generated SVG will stay within that limit. I don't usually need or want 0.0006 precision!<br /><br /><br />
<br />
<p><strong>fantasai</strong> seconds these and suggests a way of saving as Plain SVG with metadata, since<br />
things like the title, author, and license terms -- which are applicable to published images but not so<br />
much to in-process drafts -- shouldn't be thrown out with the "last used zoom level" data, which are just<br />
junk in a publication-ready image.</p><br />
<br />
<br />
== Orthogonal Lines ==<br />
njh writes:<br />
<br />
Orthogonal lines best-fit to a pen path would be useful for quickly sketching diagrams.<br />
<br />
<br />
:I think that Inkscape could adapt techniques from professional CAD Software including the Snap-Functionality:<br />
:<u>existing</u><br />
:*Snap to Nodes of a Line/Polygon<br />
:*Snap to Line<br />
:<u>missing</u><br />
:*Snap ortogonal to a Line<br />
:*Snap to Tangents of Curves<br />
:*etc. <br />
:Also there could be a kind of<br />
:<u>parametic input methods</u><br />
:* There are more than one possibility to express how a circle gets created - ie. a circle could get defined using the center and a radius/diameter, 3 tagent-points, etc.<br />
:* A line could get constructed using a startingpoint, lenght and angle<br />
:* and much more...<br />
:the way a specific line was drawn parametrically could get stored in the SVG-file as XML-Extensions using the Inksape-Namespace. <br />
:[[User:MovGP0|MovGP0]] 20:36, 6 May 2007 (UTC)<br />
<br />
== Scribus ==<br />
*Scribus is a DTP coded in C++ (but with Qt). it can work with Python Script.<br />
May be have a look at this could help doing the same in Inkscape.<br />
*If the later can be done, this will help eventually include some of good<br />
Sketch<br />
(written in Python) possibilities in Inkscape.<br />
*Also Scribus has good [[NodeTool]], and good text tool featuring textbox (frame)<br />
or text on a path.<br />
<br />
cheers<br />
Cédric<br />
<br />
== Plugins ==<br />
plugins for ways to warp and bend things<br />
<br />
== GtkVectDraw ==<br />
What I can expect from this project is a better integration with gnome-office.<br />
I dream for a really integrated gnome-office with a lot of code sharing via libraries. <br />
For example, a vectorial drawing soft has lot of things in common with glabels, [[AbiShow]], etc ... <br />
We have a lot to learn from Koffice in this respect. <br />
<br />
So please create a fully capable [[GtkVectDraw]] library !<br />
<br />
== Small core, great extensions ==<br />
''Emphasis on a small core plus modular extensions for features (a la Mozilla Firebird)''<br />
<br />
But *please* maintain a plugin-pack, and ship it with Inkscape. The way Firebird works sucks. Firebird has poor tab-implementation, and there are >10 extensions that try to improve it, while only 1 good version is needed. The list with extensions is chaos, don't let it be so with Inkscape...<br />
<br />
== Sodipodi ==<br />
The below is in regards to Sodipodi 0.32:<br />
<br />
2. The XML viewer doesn't appear to allow selecting multiple items.<br />
Often times I want to makes changes to many items at once and sometimes<br />
I'll be working in the XML viewer. Since this was the only way I could<br />
figure out how to select individual items in a group it seems completely<br />
impossible to select several items in a group.<br />
<br />
Some notes on feel:<br />
<br />
4. The mouse event system feels a bit wonky. For example, if I take a<br />
fairly complex design which can be a little bit sluggish when editing and<br />
<br />
make adjustments to a path node the cursor doesn't release as soon as I<br />
let go of the mouse button. So when I'm working quickly what happens is I<br />
tweak a node, let go of the mouse button, then move the mouse and it keeps<br />
adjusting the node even though I'm not holding the button. This slows me<br />
down considerably because I have to wait after letting go of the mouse<br />
button each time. It also does this when scrolling the main view using<br />
the middle mouse button. I'll scroll the view over, let go of the mouse<br />
button, then when I move the mouse the view still scrolls for a second or<br />
two. Very annoying. :)<br />
<br />
<br />
Feature "wants":<br />
<br />
<br />
9. More powerful selection commands. Some examples (from Illustrator):<br />
<br />
Select by fill color<br />
Select by same stroke and fill<br />
etc...<br />
<br />
<br />
11. (DONE) More and user defined hot-keys. Can I set any command/mode to a<br />
hot-key?<br />
<br />
<br />
== Gimp ==<br />
I noticed that gimp does a cool hack today, they use an image thumbnail of the drawing as the window manager icon for the drawing window, you should do that with inkscape too<br />
and it is actually usefull, consider I have fix inkscape windows with different flags, with this hack I will be able to identify each window in the tasklist and don't have to search so much<br />
<br />
Also, I really wish inkscape where session aware like gedit, so that when I asks nautilus to open a new image it does so in the existing inkscape session instead of starting a new instance<br />
<br />
http://bugzilla.gnome.org/show_bug.cgi?id=107668 - the discussion in that bug report might be of interest to you guys too. the participants are Dom (librsvg), Owen and the Gimp guys<br />
<br />
-- Uraeus<br />
<br />
<br />
== Nonexisting File ==<br />
when given a nonexisting file name on the command line, create that file (with an error report too)<br />
<br />
== TIFF-Export ==<br />
Ability to export to uncompressed TIFF.<br />
<br />
I agree. Or perhaps the ability to export a bitmap without any compression (e.g., TIFF or BMP). I would like to create arrays of individual pixels and export them as a bitmap file. After I carefully set up my bitmap with cloning and tiling and export it as a bitmap, the pixels are distorted from the compression.<br />
<br />
== Multi-Page and Layers ==<br />
<br />
Add multi-page support, default layouts for all pages, etc.<br />
<br />
== Dia-Import ==<br />
Ability to import Dia objects. <br />
Restricted Inkscape mode to work like Dia. There's nothing that Dia can do that is not possible to<br />
do in Inkscape. <br />
<br />
== Viewports ==<br />
However you gave me an idea: I can store past viewport not only before I do zoom, but also after that; later, when a next zoom is started, I will compare the current viewport with the last stored and, if it's the same, not store it. This way I will be adding one viewport record if there was no panning between zooms and two records if there was panning, these records storing the first and last viewports at this zoom. I think it will be a bit more convenient this way. <br />
<br />
:Well, what I had in mind is that viewport undo steps would be separated by editing operations -- so e.g. consecutive pans/zooms with no edits in between them would be coalesced into a single zoom undo step.<br />
<br />
== SWF-Export ==<br />
Exporting vectors as swf files. While this is probably not on the top of everyone's wishlist, it would make inkscape the tool of choice for editing shapes for flash, which is an area where the flash editor does a horrible job. Flash import capabilities for vectors are also very limited, making AI a requirement in order to convert between flash and svg.<br />
<br />
Given that svg is going to be replacing flash very (very) soon, a flash import capability would also make life easier for a lot of people...<br />
<br />
Ming library: [[http://ming.sourceforge.net/]]<br />
[[Svg2Swf]] python script (uses Ming): [[http://www.eskimo.com/~robla/svg2swf/]]<br />
<br />
One adition: users (flash devigners) should be able to create symbols and give them proper names for inFlash use.<br />
That would make Inkscape very usefull flash design platform.<br />
AI has implemented that since CS3.<br />
<br />
== Mouse/Pen gestures ==<br />
Add support for mouse gestures.<br />
I have used the Mentor Graphics CAD tools for editing<br />
schematics and PCB layouts, and the built-in support for mouse<br />
<br />
gesture has helped the productivity a lot. Granted CAD drawing<br />
is not exactly vector drawing, but it is not too far apart.<br />
There is a library libstroke that provides gestures support,<br />
but I don't have any idea how usable that would be for inkscape.<br />
<br />
<br />
:I thik there is some potential in this, ie. for undo/redo operations or tool-selection. Anyway, when you are working ie. with a tablet, its just about hitting the buttons that are doing just that. [[User:MovGP0|MovGP0]] 20:09, 6 May 2007 (UTC)<br />
<br />
== Find enhancements ==<br />
Find dialog: collapsable panes: Size & Position (X, Y, W, H; tolerance), Attribute (Name, Value). Pasting in the id, style, size/position fields (add buttons for pasting?) pastes the id, style, size/position of the object on clipboard. Add a regexp checkbox, when it's on matches are always exact but with a regexp matcher. Checkboxes: limit search to selection, (later) to current layer, possibly in (in)visible or (in)sensitive only.<br />
<br />
== Fill & Stroke ==<br />
Plan for fill&stroke:<br />
<br />
* add fill opacity/stroke opacity sliders common to all fill/stroke types (gradients, patterns, color)<br />
*:upon reflection, no. It gives nothing compared to master opacity.<br />
* maybe separate it into Fill and Stroke dialogs<br />
* change gradient display/controls to match those of the toolbar!<br />
<br />
<br />
== Transform Selection ==<br />
A new "transform with selection" toggle: font (see [[FontKerning]], toggle between [0 or 1, depending on optimize/preserve] and 2).<br />
<br />
== Corel Draw and Illustrator Import ==<br />
Filter to import Corel Draw Files and Adobe Illustrator Files<br />
(very important at my opinion)<br />
<br />
:Probabbly to dificult to do well, just export to svg<br />
<br />
:Actually, current AI files are really just PDFs - should be pretty easy<br />
<br />
== Postscript Export ==<br />
On export to Postscript, special-case treatment of text/fonts so that, instead of outputting each instance of a character as a separate set of coordinates, output the definition of the character once, and then use it (with matrix transforms) for each instance of that character.<br />
<br />
On export to Postscript, allow for specifying use of fonts-and-text (particularly useful when planning to create PDFs).<br />
<br />
On export to Postscript a) warn about transparencies, b) attempt to automatically correct for transparencies by i) converting underlying fragments to transformed values (complex) or ii) embed a bitmap-based fill. Possibly allowing optional choice of approach.<br />
<br />
Possibly provide a direct-to-PDF export as well?<br />
<br />
Possibly allow for a UI mechanism that lets any code in the system define a selection set of objects, displaying their IDs in a floating dialog. Clicking on the IDs would select the object. The postscript export warning about transparent objects, then, would be able to return with a selection set through which the user could iterate in order to fix each transparent object.<br />
<br />
Provide a saving option which gathers the fonts used by the SVG file (as well as any other externally referenced files) for transfer to another machine. Preferably stored in a zip or similar mechanism so that they're easy to share. This is basically a "collect resources" feature.<br />
<br />
<br />
:I sign this one too, because using SVG from LaTeX is hard to do. The usual approach to this is exporting all as bitmap and then use it. I think that a PS export would do much better. [[User:MovGP0|MovGP0]] 20:00, 6 May 2007 (UTC)<br />
<br />
== Print Preview ==<br />
Provide a print-preview, print-settings, page-setup style printing framework (a-la Corel, Adobe, etceteras).<br />
<br />
== Fill and Stroke Dialog Focus ==<br />
On right-click menu selection of a dialog (fill and stroke, or object properties, for instance), set focus to the dialog selected to avoid the need for a mouse-seek-and-click to do the set-focus.<br />
<br />
== Tiled Cones ==<br />
Under the "Rotation" tab of the "Create Tiled Clones" menu, perhaps have<br />
an "Anchor Offset" option "as well as a setting for (px, cm, mm, in, etc - default "px") which could remain at "0" or "centered" or be changed<br />
relative to center, say (+ or -) and (x or y):<br />
<br />
x = 50, y = 50; x = 50, y = -50; x = -50, y = -50; x = -50, y = 50<br />
<br />
etc.<br />
<br />
This would allow for explicit placement of the rotation anchor.<br />
<br />
This could also be used for general rotation as well.<br />
<br />
== MathML Import ==<br />
For scientific graphics I often need the possibility to write mathematical Formulas within the SVG-File. A possible way to do so is write the Formulas using TeX, convert to MathML (this is the easy part) convert to PNG and then import to use it. But a Bitmap that is not good for scaling, so you better transform MathML to SVG and import the SVG. <br />
<br />
I think that Inkscape should come with a Plugin that can do the MathML to SVG transformation. Later this tool could get extended to convert also simple TeX to MathML to SVG. <br />
<br />
Having such a plugin, complex Formulas could get transformed like any SVG (including scaling, rotation, coloring, etc.), but keept as plain MathML in the Sourcecode. This will make inkscape really useful for scientific and technical needs. <br />
<br />
[[User:MovGP0|MovGP0]] 19:57, 6 May 2007 (UTC)<br />
<br />
Maybe, [http://helm.cs.unibo.it/mml-widget/ GtkMathView] can be used to render MathML into SVG.<br />
<br />
== Metadata in Save-Dialog ==<br />
I think that the Button for editing Document-Metadata should also be shown in the File-Save Dialog, because lazy peoples like myself are ignoring such possibilities if there are not easily accessible. <br />
<br />
I think a Button that asks for filling Metadata and another Button for choosing a License (if not filled/choosen already) in the File-Save Dialog would be a good idea. <br />
<br />
[[User:MovGP0|MovGP0]] 20:21, 6 May 2007 (UTC)<br />
<br />
== SVG Profile Selection ==<br />
There should be a possibility to choose which SVG-Standard a user want to use for his drawing. If choosen one, Inkscape should only show tools that are supported in this standard. So, if a user chooses to use "SVG Mobile 1.0" it doesn't makes sense to present a "SVG 1.2 Full"-only-tool. [[User:MovGP0|MovGP0]] 20:48, 6 May 2007 (UTC)<br />
<br />
== Inkscape as Tablet Notepad ==<br />
My purpose is to be able, e.g., to open an inkscape document from an OO presentation, to use as a blackboard, something I can do with gimp (but Inkscape is much better!). Is there a workaround? I could think of a simple one<br />
if Inkscape had also a specific extension (an alias), different from .svg.<br />
No special format, simply a dedicated extension. Mime processing would then send the file to Inkscape, not to a viewer, as it is now.<br />
Does this make any sense?<br />
<br />
== 3D Color Picker ==<br />
<br />
Color is inherently three dimensional, and http://www.colorotate.org is a 3D editor that "aligns with the way our minds process color" - http://learn.colorotate.org/ explains color nicely. ColoRotate is kinda like Adobe Kuler, but with a 3D representation its even better. I'd like to see a widget like this in Inkscape! :-)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=54771Save Cleaned SVG2009-11-15T18:33:06Z<p>Tsingi: </p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
** Collapse multiple redundent groups<br />
** Remove empty tags, such as defs or metadata.<br />
** Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
** Remove unused definitions<br />
** Remove duplicate gradient stops<br />
** Collapse duplicate gradient definitions<br />
** Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
** Remove Default values, i.e. opacity: 1;<br />
** Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
** Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
** Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
** Detect vertical/horizontal lines and replace.<br />
** Eliminate empty path segments<br />
** Eliminate last segment in a polygon<br />
** Collapse straight curves.<br />
** Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
** Process quadratic Bezier curves<br />
** Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
** css to element attributes<br />
* Output Standard SVG<br />
** Remove inkscape namespace<br />
** Remove sodipodi namespace<br />
** Remove adobe namespace<br />
** Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
=== SVG Tidy ===<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
See: http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
=== Scour ===<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
See: http://codedread.com/scour/<br />
<br />
=== islint ===<br />
<br />
* Another project: (depricated, see NOTE below) [[islint]] (wiki link), InkScape lint is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
NOTE: I changed the name from islint to svglint, I'm in the process of creating the project. svglint is a more recognizable name and islint implies that the tool is only for inkscape. I got ambitious.<br />
<br />
I've also thrown out the old code completely, call it the first waffle.<br />
<br />
See: http://svglint.sourceforge.net/ (project link)<br />
<br />
--[[User:Tsingi|Tsingi]] 17:31, 14 November 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=54753Save Cleaned SVG2009-11-14T17:31:36Z<p>Tsingi: </p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
** Collapse multiple redundent groups<br />
** Remove empty tags, such as defs or metadata.<br />
** Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
** Remove unused definitions<br />
** Remove duplicate gradient stops<br />
** Collapse duplicate gradient definitions<br />
** Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
** Remove Default values, i.e. opacity: 1;<br />
** Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
** Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
** Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
** Detect vertical/horizontal lines and replace.<br />
** Eliminate empty path segments<br />
** Eliminate last segment in a polygon<br />
** Collapse straight curves.<br />
** Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
** Process quadratic Bezier curves<br />
** Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
** css to element attributes<br />
* Output Standard SVG<br />
** Remove inkscape namespace<br />
** Remove sodipodi namespace<br />
** Remove adobe namespace<br />
** Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
=== SVG Tidy ===<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
See: http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
=== Scour ===<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
See: http://codedread.com/scour/<br />
<br />
=== islint ===<br />
<br />
* Another project: [[islint]] (wiki link), InkScape lint is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
NOTE: I changed the name from islint to svglint, I'm in the process of creating the project. svglint is a more recognizable name and islint implies that the tool is only for inkscape. I got ambitious.<br />
<br />
I've also thrown out the old code completely, call it the first waffle.<br />
<br />
See: http://svglint.sourceforge.net/ (project link)<br />
<br />
--[[User:Tsingi|Tsingi]] 17:31, 14 November 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53913Islint2009-09-27T14:38:35Z<p>Tsingi: </p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
= Contents =<br />
<br />
* [http://wiki.inkscape.org/wiki/index.php/Islint-implementation islint implementation]</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint-implementation&diff=53911Islint-implementation2009-09-27T14:37:26Z<p>Tsingi: </p>
<hr />
<div>linked from [http://wiki.inkscape.org/wiki/index.php/Islint islint]<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE v0.8''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE v0.8''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
<br />
== Implementation Notes ==<br />
<br />
I'll keep track of what I do, am doing here. v0.8 is the version as of this writing.<br />
<br />
=== CSS Styling v0.8 ===<br />
<br />
Currently islint either creates inline CSS style sheets, or leaves styling alone. Only style attributes are processed.<br />
* TODO: <br />
** parse XML style attributes (stroke=, fill=)<br />
** implement options for document styling:<br />
*** CSS (inline or external)<br />
*** style attributes<br />
*** standalone XML attributes<br />
<br />
<br />
<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53909Islint2009-09-27T14:35:27Z<p>Tsingi: /* Contents */</p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
= Contents =<br />
<br />
[./islint-implementation]</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53907Islint2009-09-27T14:32:21Z<p>Tsingi: Replaced content with 'These are notes on islint requirements and implementation.
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]
This page lin...'</p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
= Contents =<br />
<br />
[[islint-implementation]]</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint-implementation&diff=53905Islint-implementation2009-09-27T14:30:39Z<p>Tsingi: 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...'</p>
<hr />
<div>== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE v0.8''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE v0.8''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
<br />
== Implementation Notes ==<br />
<br />
I'll keep track of what I do, am doing here. v0.8 is the version as of this writing.<br />
<br />
=== CSS Styling v0.8 ===<br />
<br />
Currently islint either creates inline CSS style sheets, or leaves styling alone. Only style attributes are processed.<br />
* TODO: <br />
** parse XML style attributes (stroke=, fill=)<br />
** implement options for document styling:<br />
*** CSS (inline or external)<br />
*** style attributes<br />
*** standalone XML attributes<br />
<br />
<br />
<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53903Islint2009-09-27T14:30:01Z<p>Tsingi: </p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
[[islint-implementation]]<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE v0.8''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE v0.8''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
<br />
== Implementation Notes ==<br />
<br />
I'll keep track of what I do, am doing here. v0.8 is the version as of this writing.<br />
<br />
=== CSS Styling v0.8 ===<br />
<br />
Currently islint either creates inline CSS style sheets, or leaves styling alone. Only style attributes are processed.<br />
* TODO: <br />
** parse XML style attributes (stroke=, fill=)<br />
** implement options for document styling:<br />
*** CSS (inline or external)<br />
*** style attributes<br />
*** standalone XML attributes<br />
<br />
<br />
<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53897Islint2009-09-24T14:30:55Z<p>Tsingi: /* Implementation Notes */</p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE v0.8''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE v0.8''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
<br />
== Implementation Notes ==<br />
<br />
I'll keep track of what I do, am doing here. v0.8 is the version as of this writing.<br />
<br />
=== CSS Styling v0.8 ===<br />
<br />
Currently islint either creates inline CSS style sheets, or leaves styling alone. Only style attributes are processed.<br />
* TODO: <br />
** parse XML style attributes (stroke=, fill=)<br />
** implement options for document styling:<br />
*** CSS (inline or external)<br />
*** style attributes<br />
*** standalone XML attributes<br />
<br />
<br />
<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53895Islint2009-09-24T12:58:14Z<p>Tsingi: /* Output Standard SVG */</p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE v0.8''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE v0.8''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
<br />
== Implementation Notes ==<br />
<br />
I'll keep track of what I do here. v0.8 is the version as of this writing.<br />
<br />
=== CSS Styling v0.8 ===<br />
<br />
Currently islint either creates inline CSS style sheets, or leaves styling alone. Only style attributes are processed.<br />
* TODO: <br />
** parse XML style attributes (stroke=, fill=)<br />
** implement options for document styling:<br />
*** CSS (inline or external)<br />
*** style attributes<br />
*** standalone XML attributes<br />
<br />
<br />
<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53893Islint2009-09-24T12:49:13Z<p>Tsingi: /* Output Standard SVG */</p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE v0.8''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE v0.8''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53891Islint2009-09-24T12:48:18Z<p>Tsingi: </p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE v0.8''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE v0.8''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53889Save Cleaned SVG2009-09-24T12:44:19Z<p>Tsingi: </p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
** Collapse multiple redundent groups<br />
** Remove empty tags, such as defs or metadata.<br />
** Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
** Remove unused definitions<br />
** Remove duplicate gradient stops<br />
** Collapse duplicate gradient definitions<br />
** Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
** Remove Default values, i.e. opacity: 1;<br />
** Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
** Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
** Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
** Detect vertical/horizontal lines and replace.<br />
** Eliminate empty path segments<br />
** Eliminate last segment in a polygon<br />
** Collapse straight curves.<br />
** Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
** Process quadratic Bezier curves<br />
** Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
** css to element attributes<br />
* Output Standard SVG<br />
** Remove inkscape namespace<br />
** Remove sodipodi namespace<br />
** Remove adobe namespace<br />
** Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
=== SVG Tidy ===<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
See: http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
=== Scour ===<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
See: http://codedread.com/scour/<br />
<br />
=== islint ===<br />
<br />
* Another project: [[islint]] (wiki link), InkScape lint is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/ (project link)<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53887Save Cleaned SVG2009-09-24T12:43:14Z<p>Tsingi: </p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
** Collapse multiple redundent groups<br />
** Remove empty tags, such as defs or metadata.<br />
** Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
** Remove unused definitions<br />
** Remove duplicate gradient stops<br />
** Collapse duplicate gradient definitions<br />
** Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
** Remove Default values, i.e. opacity: 1;<br />
** Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
** Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
** Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
** Detect vertical/horizontal lines and replace.<br />
** Eliminate empty path segments<br />
** Eliminate last segment in a polygon<br />
** Collapse straight curves.<br />
** Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
** Process quadratic Bezier curves<br />
** Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
** css to element attributes<br />
* Output Standard SVG<br />
** Remove inkscape namespace<br />
** Remove sodipodi namespace<br />
** Remove adobe namespace<br />
** Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
See: http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
See: http://codedread.com/scour/<br />
<br />
* Another project: [[islint]] (wiki link), InkScape lint is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/ (project link)<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53885Save Cleaned SVG2009-09-24T12:42:19Z<p>Tsingi: </p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
** Collapse multiple redundent groups<br />
** Remove empty tags, such as defs or metadata.<br />
** Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
** Remove unused definitions<br />
** Remove duplicate gradient stops<br />
** Collapse duplicate gradient definitions<br />
** Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
** Remove Default values, i.e. opacity: 1;<br />
** Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
** Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
** Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
** Detect vertical/horizontal lines and replace.<br />
** Eliminate empty path segments<br />
** Eliminate last segment in a polygon<br />
** Collapse straight curves.<br />
** Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
** Process quadratic Bezier curves<br />
** Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
** css to element attributes<br />
* Output Standard SVG<br />
** Remove inkscape namespace<br />
** Remove sodipodi namespace<br />
** Remove adobe namespace<br />
** Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
http://codedread.com/scour/<br />
<br />
* Another project: [[islint]] (wiki link), InkScape lint is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/ (project link)<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53883Save Cleaned SVG2009-09-24T12:41:45Z<p>Tsingi: </p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
** Collapse multiple redundent groups<br />
** Remove empty tags, such as defs or metadata.<br />
** Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
** Remove unused definitions<br />
** Remove duplicate gradient stops<br />
** Collapse duplicate gradient definitions<br />
** Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
** Remove Default values, i.e. opacity: 1;<br />
** Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
** Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
** Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
** Detect vertical/horizontal lines and replace.<br />
** Eliminate empty path segments<br />
** Eliminate last segment in a polygon<br />
** Collapse straight curves.<br />
** Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
** Process quadratic Bezier curves<br />
** Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
** css to element attributes<br />
* Output Standard SVG<br />
** Remove inkscape namespace<br />
** Remove sodipodi namespace<br />
** Remove adobe namespace<br />
** Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
http://codedread.com/scour/<br />
<br />
* Another project: [[islint]] (wiki link), (InkScape lint) It is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/ (project link)<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53881Islint2009-09-24T12:37:30Z<p>Tsingi: </p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
This page links from [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG Save_Cleaned_SVG]<br />
<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53879User:Tsingi2009-09-24T12:35:51Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
* [http://wiki.inkscape.org/wiki/index.php/Islint islint requirements] note on this wiki<br />
<br />
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.<br />
<br />
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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53877User:Tsingi2009-09-24T12:35:36Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
* [http://wiki.inkscape.org/wiki/index.php/Islint islint requirements] note on this wiki<br />
<br />
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.<br />
<br />
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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53875Islint2009-09-24T12:33:54Z<p>Tsingi: </p>
<hr />
<div>These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
<br />
== Wiki Notes Annotated ==<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53873Islint2009-09-24T12:33:24Z<p>Tsingi: /* islint */</p>
<hr />
<div><br />
These are notes on islint requirements and implementation.<br />
<br />
islint is an SVG a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53871Islint2009-09-24T12:32:52Z<p>Tsingi: </p>
<hr />
<div>= islint =<br />
<br />
These are notes on islint requirements and implementation.<br />
<br />
islint a profiling filter found at [https://sourceforge.net/projects/islint/ sourceforge]<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53869Islint2009-09-24T12:30:38Z<p>Tsingi: /* Process Transformations */</p>
<hr />
<div>= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/Islint#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53867Islint2009-09-24T12:29:21Z<p>Tsingi: </p>
<hr />
<div>= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
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.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/User:Tsingi#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.<br />
--[[User:Tsingi|Tsingi]] 12:29, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Islint&diff=53865Islint2009-09-24T12:28:50Z<p>Tsingi: Created page with '= 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 pe...'</p>
<hr />
<div>= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
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.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/User:Tsingi#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53863Save Cleaned SVG2009-09-24T12:28:18Z<p>Tsingi: /* Reference Work */</p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
* Collapse multiple redundent groups<br />
* Remove empty tags, such as defs or metadata.<br />
* Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
* Remove unused definitions<br />
* Remove duplicate gradient stops<br />
* Collapse duplicate gradient definitions<br />
* Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
* Remove Default values, i.e. opacity: 1;<br />
* Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
* Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
* Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
* Detect vertical/horizontal lines and replace.<br />
* Eliminate empty path segments<br />
* Eliminate last segment in a polygon<br />
* Collapse straight curves.<br />
* Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
* Process quadratic Bezier curves<br />
* Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
* css to element attributes<br />
* Output Standard SVG<br />
* Remove inkscape namespace<br />
* Remove sodipodi namespace<br />
* Remove adobe namespace<br />
* Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
http://codedread.com/scour/<br />
<br />
* Another project: [[islint]], (InkScape lint) It is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53861Save Cleaned SVG2009-09-24T12:27:03Z<p>Tsingi: </p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
* Collapse multiple redundent groups<br />
* Remove empty tags, such as defs or metadata.<br />
* Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
* Remove unused definitions<br />
* Remove duplicate gradient stops<br />
* Collapse duplicate gradient definitions<br />
* Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
* Remove Default values, i.e. opacity: 1;<br />
* Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
* Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
* Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
* Detect vertical/horizontal lines and replace.<br />
* Eliminate empty path segments<br />
* Eliminate last segment in a polygon<br />
* Collapse straight curves.<br />
* Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
* Process quadratic Bezier curves<br />
* Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
* css to element attributes<br />
* Output Standard SVG<br />
* Remove inkscape namespace<br />
* Remove sodipodi namespace<br />
* Remove adobe namespace<br />
* Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
http://codedread.com/scour/<br />
<br />
* Another project: [./islint islint], (InkScape lint) It is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53859Save Cleaned SVG2009-09-24T12:26:29Z<p>Tsingi: /* Reference Work */</p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
* Collapse multiple redundent groups<br />
* Remove empty tags, such as defs or metadata.<br />
* Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
* Remove unused definitions<br />
* Remove duplicate gradient stops<br />
* Collapse duplicate gradient definitions<br />
* Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
* Remove Default values, i.e. opacity: 1;<br />
* Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
* Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
* Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
* Detect vertical/horizontal lines and replace.<br />
* Eliminate empty path segments<br />
* Eliminate last segment in a polygon<br />
* Collapse straight curves.<br />
* Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
* Process quadratic Bezier curves<br />
* Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
* css to element attributes<br />
* Output Standard SVG<br />
* Remove inkscape namespace<br />
* Remove sodipodi namespace<br />
* Remove adobe namespace<br />
* Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
http://codedread.com/scour/<br />
<br />
* Another project: '''[./islint islint]''', (InkScape lint) It is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=Save_Cleaned_SVG&diff=53857Save Cleaned SVG2009-09-24T12:26:16Z<p>Tsingi: /* Reference Work */</p>
<hr />
<div>= Create Cleaned SVG =<br />
<br />
Please fix this wiki page if it doesn't fit the standard blueprint template.<br />
<br />
== Rationale ==<br />
<br />
We're working on a proposal and design for allowing a plugin which saves svg data with various things striped and adjusted. Useful for scripting, templating with svg, editing later in a text editor and keeping files small for internet transfer.<br />
<br />
== Technologies ==<br />
<br />
* Python<br />
* python-xml<br />
* inkscape plugin svg/python module<br />
<br />
== Presented Options ==<br />
<br />
The save format would not be totally pre-set or blind but would instead be based on the options selected by the user in a single, simple dialogue much like the pdf export dialogue.<br />
<br />
== Cleaning Operations ==<br />
<br />
* Specify a limit to the precision of all positional elements.<br />
* Clean up XML Elements<br />
* Collapse multiple redundent groups<br />
* Remove empty tags, such as defs or metadata.<br />
* Remove id tags for elements not referenced<br />
* Clean up Definitions<br />
* Remove unused definitions<br />
* Remove duplicate gradient stops<br />
* Collapse duplicate gradient definitions<br />
* Remove gradients that are only referenced by one other gradient<br />
* Clean up CSS<br />
* Remove Default values, i.e. opacity: 1;<br />
* Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;<br />
* Convert RGB colours from RGB(r,g,b) to #RRGGBB format<br />
* Convert RGB colours from #RRGGBB to #RGB if possible<br />
* Clean up paths<br />
* Detect vertical/horizontal lines and replace.<br />
* Eliminate empty path segments<br />
* Eliminate last segment in a polygon<br />
* Collapse straight curves.<br />
* Convert absolute path segments to relative ones.<br />
* Process Transformations<br />
* Process quadratic Bezier curves<br />
* Collapse all group based transformations<br />
* Convert known properties to element attributes<br />
* css to element attributes<br />
* Output Standard SVG<br />
* Remove inkscape namespace<br />
* Remove sodipodi namespace<br />
* Remove adobe namespace<br />
* Use viewPort instead of document width/height<br />
<br />
== Tests ==<br />
<br />
Testing of this code can be done automatically with a single good logical test. And should be written first. This involves a single svg document with all the worst noise and each ideal document output from that based on each operation. The test would be simply if the output is reached it passes.<br />
<br />
== Reference Work ==<br />
<br />
* This script has been created in Ruby where some of the ideas have been pulled:<br />
<br />
http://www.intertwingly.net/blog/2008/02/01/SVG-Tidy<br />
<br />
* NOTE: scour (a Python script) has since been developed to automate the cleaning of SVG files. Most of the points on this page have been covered. Suggest using scour as the basis for the Inkscape plugin.<br />
<br />
http://codedread.com/scour/<br />
<br />
* Another project: '''[./islint islint]''', (InkScape lint) It is implemented with an InkScape "Save As" filter. Some different priorities than the above were assumed, i.e. islint creates a CSS style sheet. It was written to target web development. The points above are under review (with the other scripts found here) An exacting test page would be ''very'' beneficial.<br />
<br />
See: http://islint.sourceforge.net/<br />
<br />
--[[User:Tsingi|Tsingi]] 07:48, 24 September 2009 (UTC)</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53855User:Tsingi2009-09-24T12:00:52Z<p>Tsingi: /* Process Transformations */</p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
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.<br />
* '''''css to element attributes'''''<br />
see ''[http://wiki.inkscape.org/wiki/index.php/User:Tsingi#Clean_up_CSS Clean up CSS]'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53853User:Tsingi2009-09-24T11:58:57Z<p>Tsingi: /* Process Transformations */</p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=), see ''Clean up CSS'' above.<br />
* '''''css to element attributes'''''<br />
see ''Clean up CSS'' above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53851User:Tsingi2009-09-24T11:56:26Z<p>Tsingi: /* Process Transformations */</p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=) it is discussed above<br />
* '''''css to element attributes'''''<br />
As above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53849User:Tsingi2009-09-24T11:55:41Z<p>Tsingi: /* Process Transformations */</p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these first two points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
If this means convert the css properties in style attributes to standalone XML attributes (fill=, stroke=) is is discussed above<br />
* '''''css to element attributes'''''<br />
As above.<br />
<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53847User:Tsingi2009-09-24T11:53:52Z<p>Tsingi: /* Clean up CSS */</p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''.<br />
<br />
''DONE''. I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
* '''''css to element attributes'''''<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53845User:Tsingi2009-09-24T11:52:07Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. <br />
''DONE'' I convert everything to rgb(...) because I like it for programmability and the CSS DOM seems to like them.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
* '''''css to element attributes'''''<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53843User:Tsingi2009-09-24T11:48:12Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
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?<br />
: 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. <br />
: It would be easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
* '''''css to element attributes'''''<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53841User:Tsingi2009-09-24T11:43:03Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
* '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
* '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
* '''''Remove unused definitions'''''<br />
* '''''Remove duplicate gradient stops'''''<br />
* '''''Collapse duplicate gradient definitions'''''<br />
* '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
islint implements inline CSS style sheets by parsing the style attributes (style=) into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
: 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. Once that is done, it would be as easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
* '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
* '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
* '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
* '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
=== Clean up paths ===<br />
''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.<br />
* '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
* '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
* '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
* '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
* '''''Process quadratic Bezier curves'''''<br />
* '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
* '''''css to element attributes'''''<br />
=== Output Standard SVG ===<br />
''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.<br />
* '''''Remove inkscape namespace'''''<br />
* '''''Remove sodipodi namespace'''''<br />
* '''''Remove adobe namespace'''''<br />
* '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53839User:Tsingi2009-09-24T11:41:28Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
=== Specify a limit to the precision of all positional elements. ===<br />
''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.<br />
=== Clean up XML Elements ===<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
=== Clean up Definitions ===<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
=== Clean up CSS ===<br />
islint implements inline CSS style sheets by parsing the style attributes (style=) into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
: 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. Once that is done, it would be as easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
=== Clean up paths ===<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
=== Process Transformations ===<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
=== Output Standard SVG ===<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53837User:Tsingi2009-09-24T11:38:20Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style=) into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
: 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. Once that is done, it would be as easy to convert to all style attributes, or standalone XML attributes instead of an inline style sheet.<br />
<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53835User:Tsingi2009-09-24T11:33:02Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style=) into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53833User:Tsingi2009-09-24T11:30:53Z<p>Tsingi: /* Wiki Notes Annotated */</p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style=) into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53831User:Tsingi2009-09-24T11:27:08Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style='') into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53829User:Tsingi2009-09-24T11:25:54Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on islint ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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 that 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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style='') into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53827User:Tsingi2009-09-24T11:25:39Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== notes on isling ===<br />
<br />
'''This is the wrong place to do this, but it will serve for now...'''<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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 that 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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style='') into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53825User:Tsingi2009-09-24T11:25:02Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
This is the wrong place to do this, but it will serve for now...<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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 that 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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. ''Status, difficulty, priority like this''.<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style='') into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53823User:Tsingi2009-09-24T11:24:32Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
This is the wrong place to do this, but it will serve for now...<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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 that 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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. '''Status, difficulty, priority like this'''<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
''Not done, easy, low priority''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
''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.<br />
* '''''Clean up Definitions'''''<br />
''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style='') into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
''DONE''.<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
''Not done, easy, med priority''. I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
''Not done, easy, med priority''.<br />
* '''''Clean up paths'''''<br />
''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
''Not done, easy, high priority''.<br />
** '''''Eliminate empty path segments'''''<br />
''Not done, easy, high priority''. I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
''Not done, easy, high priority''.<br />
** '''''Collapse straight curves.'''''<br />
''Not done, ???, med priority''.<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
''Not done, easy, high priority''.<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53821User:Tsingi2009-09-24T11:20:16Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
This is the wrong place to do this, but it will serve for now...<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
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 that 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.<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. '''Status, difficulty, priority like this'''<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
'''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
'''Not done, easy, low priority'''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
'''Not done, easy, low priority'''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
'''Not done, easy''' 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, '''low priority'''<br />
* '''''Clean up Definitions'''''<br />
'''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.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
islint implements inline CSS style sheets by parsing the style attributes (style='') into a table removing defaults, merging them, substituting class attributes, and 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. 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?<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
'''DONE'''<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
'''Not done, easy, med priority''' I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
'''Not done, easy, med priority'''<br />
* '''''Clean up paths'''''<br />
'''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.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
'''Not done, easy, high priority'''<br />
** '''''Eliminate empty path segments'''''<br />
'''Not done, easy, high priority''' I didn't know there were any.<br />
** '''''Eliminate last segment in a polygon'''''<br />
'''Not done, easy, high priority'''<br />
** '''''Collapse straight curves.'''''<br />
'''Not done, ???, med priority'''<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
'''Not done, easy, high priority'''<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
'''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.<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''<br />
'''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.</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53819User:Tsingi2009-09-24T10:55:35Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
This is the wrong place to do this, but it will serve for now...<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. '''Status, difficulty, priority like this'''<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
'''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
'''Not done, easy, low priority'''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
'''Not done, easy, low priority'''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
'''Not done, easy''' 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, '''low priority'''<br />
* '''''Clean up Definitions'''''<br />
'''Not done, moderate, low priority''' Generally I think this section needs a bit of work. I don't use InkScape for gradients at all, but I could. InkScape creates a lot of gradients and creates and references linear gradients when it needs a radial gradient. It should be possible to do a lot of cleanup here.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
'''DONE'''<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
Not sure what is meant here.<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
'''Not done, easy, med priority''' I convert everything to rgb(...), can do this too.<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
'''Not done, easy, med priority'''<br />
* '''''Clean up paths'''''<br />
'''DONE''' 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 and then puts them back together being very stingy with white space. A lot of work was done for this, so the code is in good shape for further reduction operations on paths.<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
'''Not done, easy, high priority'''<br />
** '''''Eliminate empty path segments'''''<br />
'''Not done, easy, high priority'''<br />
** '''''Eliminate last segment in a polygon'''''<br />
'''Not done, easy, high priority'''<br />
** '''''Collapse straight curves.'''''<br />
'''Not done, ???, med priority'''<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
'''Not done, easy, high priority'''<br />
* '''''Process Transformations'''''<br />
Do not understand these points, process Beziers how? Collapse transforms how?<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''</div>Tsingihttps://wiki.inkscape.org/wiki/index.php?title=User:Tsingi&diff=53817User:Tsingi2009-09-24T10:38:56Z<p>Tsingi: </p>
<hr />
<div>I've started contributing to InkScape in my own way, I have made a dent on a filter to sanitize InkScape.<br />
<br />
* Wiki profiler page: [http://wiki.inkscape.org/wiki/index.php/Save_Cleaned_SVG#Cleaning_Operations Save_Cleaned_SVG]<br />
* islint at [http://islint.sourceforge.net/ SourceForge]<br />
<br />
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.<br />
<br />
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.<br />
<br />
This is the wrong place to do this, but it will serve for now...<br />
<br />
= islint =<br />
<br />
=== Wiki Notes Annotated ===<br />
<br />
'''''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'''''<br />
<br />
Notes are formatted like this. '''Status, difficulty, priority like this'''<br />
<br />
* '''''Specify a limit to the precision of all positional elements.'''''<br />
'''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.<br />
* '''''Clean up XML Elements'''''<br />
** '''''Collapse multiple redundant groups'''''<br />
'''Not done, easy, Low priority'''.<br />
** '''''Remove empty tags, such as defs or metadata.'''''<br />
'''Not done, easy, Low priority'''.<br />
** '''''Remove id tags for elements not referenced'''''<br />
'''Not done, easy''' 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, '''low priority'''<br />
* '''''Clean up Definitions'''''<br />
'''Not done, moderate, low priority''' Generally I think this section needs a bit of work. I don't use InkScape for gradients at all, but I could. InkScape creates a lot of gradients and creates and references linear gradients when it needs a radial gradient. It should be possible to do a lot of cleanup here.<br />
** '''''Remove unused definitions'''''<br />
** '''''Remove duplicate gradient stops'''''<br />
** '''''Collapse duplicate gradient definitions'''''<br />
** '''''Remove gradients that are only referenced by one other gradient'''''<br />
* '''''Clean up CSS'''''<br />
** '''''Remove Default values, i.e. opacity: 1;'''''<br />
** '''''Remove Not applicable values, i.e. opacity: 0; fill-color: #00000;'''''<br />
** '''''Convert RGB colours from RGB(r,g,b) to #RRGGBB format'''''<br />
** '''''Convert RGB colours from #RRGGBB to #RGB if possible'''''<br />
* '''''Clean up paths'''''<br />
** '''''Detect vertical/horizontal lines and replace.'''''<br />
** '''''Eliminate empty path segments'''''<br />
** '''''Eliminate last segment in a polygon'''''<br />
** '''''Collapse straight curves.'''''<br />
** '''''Convert absolute path segments to relative ones.'''''<br />
* '''''Process Transformations'''''<br />
** '''''Process quadratic Bezier curves'''''<br />
** '''''Collapse all group based transformations'''''<br />
* '''''Convert known properties to element attributes'''''<br />
** '''''css to element attributes'''''<br />
* '''''Output Standard SVG'''''<br />
** '''''Remove inkscape namespace'''''<br />
** '''''Remove sodipodi namespace'''''<br />
** '''''Remove adobe namespace'''''<br />
** '''''Use viewPort instead of document width/height'''''</div>Tsingi