SVG WorkingGroup

Inkscape and the SVG Working Group

Inkscape can influence the future of the SVG standard. This page serves as a gathering point for ideas on how the standard can be improved to the benefit of Inkscape.

Inkscape representitive

Tavmjong Bah has joined the SVG Working group as an "Invited Expert" to represent the interests of Inkscape. You can contact him through the developer's mailing list or at tavmjong at free.fr. You can also join the meetings yourself (as several Inkscapers did after LGM2010). See the links below.

Please add to this page any problems you have found with the existing standard or what you would like to see in a future standard.

SVG Working Group Links

General

• Working Group Main Page
• Public-SVG-WG Mail Archives
• WWW-SVG Mail Archives (The true public mailing list).
• Schedule

Standards

• Complete List

Completed

• SVG 1.1
• SVG Tiny 1.2

Proposed Standards

• Roadmap

Areas of Inkscape Interest

Here are some areas to consider:

Multipage document support

Proposed for SVG 1.2 but dropped.

Standardizing layers

Creating a standard way to indicate layers. Inkscape uses private attributes.

Clones/referencing

Currently there is the use element, but there are also elements (gradients and filters) that have their own "cloning" technique, it could be nice to unify these approaches? In particular, either might benefit from some kind of support for "parameters" (being either numerical/textual values or drawable elements).

(Fancy) paths

• Vector effects: SVG 1,2.
• Patterns along paths.
• Power stroke: description.
• Fix "closing" path.

A different notion of "closing" a path is needed, as the current one only operates well in the context of straight lines. For example, instead of having z be a command that draws a straight line to the first vertex in the subpath and closes the path, it could be used in place of the last pair of coordinates in a closed subpath. This would only very slightly complicate parsing while allowing for a much more natural operation in the context of curves. Currently a closed path consisting (conceptually) only of cubic beziers HAS to have at least one "closing" segment, this introduces "double" nodes, is more verbose and makes it impossible to have the exact same marker behaviour in paths consisting of straight lines and paths consisting of curves. (Also see this discussion: http://old.nabble.com/Re:--Lib2geom-devel--Geom::Path-and-boost::ptr_vector-td27535646.html)

Gradients

• Diffusion curves.
• Mesh gradients.

SVG fonts

Firefox and IE will not add support for SVG fonts.

Filters

• Increasing bit depth to reduce artifacts.
• The same color space (by default) as the rest of SVG (and only ONE property please). Note that it would make sense to make linearRGB the default everywhere (instead of making filters use sRGB by default as well).
• Margins. (--Jaspervdg 13:49, 15 June 2010 (UTC) I would prefer them not to have any attributes for margins. Specifically I think the only property of the filter element that should stay is primitiveUnits.)
• Primitive subregions are (as far as I, Jasper, know) unused and frankly not that useful. As far as I can tell they're mostly meant as an optimization, but a renderer can do that quite easily (and frankly often still has to). If you want a clipping rectangle or something, then just draw a rectangle and use it to clip a result, if you have a smart renderer it will even automagically behave reasonably efficient in such a case.
• Non-pixel-based convolution (based on a Laplace transform instead of the Z-transform basically). E.g. it would be more logical (at least in some cases) to specify that you want the derivative of an image rather than applying the kernel "1 -1"... (Which has to be given a certain resolution to be meaningful, meaning that you currently can't express resolution-independent convolutions.) In fact, it could make sense to simply remove the current feConvolveMatrix, and/or enable it to function in a resolution independent manner.
• Unification of normal compositing, feBlend, feComposite and feMerge. (Like in SVG Compositing? And then exposing that in filters in some way?)
• Is enable-background REALLY necessary? There are other ways to solve the same problem, like referencing an element explicitly or allowing filters (and possibly also use elements) with "parameters". There are certain very cool things you can do with enable-background, but it's quite hard to implement correctly because you need to keep track of where the background is used in order to know which part of an object is actually needed. Other options might be less general w.r.t. accessing the "background", but they might be easier to support and allow for much more interesting effects.
• Reusing filters as primitives. (Essentially allowing macro's.)
• A lot of filters could be "optimized" by a renderer. This would be especially helpful for editors and animation-enabled renderers. It might be good to see if some things could be built in to make this easier. I would avoid explicit flags as much as possible (users either won't use them when they could, or use them all the time, negating their usefulness), but the specification might specify some operations that are explicitly permitted for example (like collapsing two feColorMatrix operations).

--Jaspervdg 16:12, 15 June 2010 (UTC) In general I'd like to stress that SVG filters should (IMO) focus less on a specific implementation and more on the desired effect (and if possible in a "vector-like" way). This makes it less complex to support filters and gives more freedom to an implementation to "do the right thing" in its own way. It's also more friendly towards the user of SVG, as more of the implementation details are hidden. (Obviously it should be possible to implement a filter, but the specification shouldn't prescribe a certain implementation.)

Cacheable portion/layers

• Investigate partial.s cache-ablity