SVG WorkingGroup - Revision history

Tavmjong: /* Proposed Standards */

2010-06-20T06:19:22Z

Proposed Standards

← Older revision		Revision as of 06:19, 20 June 2010
Line 30:		Line 30:
	==== Proposed Standards ====		==== Proposed Standards ====

	*[http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap Roadmap]		*[http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap Roadmap] (out of date, will be updated soon).


	== Areas of Inkscape Interest ==		== Areas of Inkscape Interest ==

Tavmjong: /* Filters */

2010-06-20T06:12:00Z

Filters

← Older revision		Revision as of 06:12, 20 June 2010
Line 87:		Line 87:

	=== Filters ===		=== Filters ===

			See: [http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html SVG 1.2 filter module].


			*Color space
			: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
			:--[[User:Jaspervdg\|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?)

			*enable-background
			: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.)

			*Optimization
			: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).

	*Increasing bit depth to reduce artifacts.		*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. (--[[User:Jaspervdg\|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).

	--[[User:Jaspervdg\|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.)		--[[User:Jaspervdg\|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.)
			:--Tav: There is a proposal to include a special 'feDropShadow' filter.

	=== Cacheable portion/layers ===		=== Cacheable portion/layers ===

	*Investigate partial.s cache-ablity		*Investigate partial.s cache-ablity

Tavmjong: /* SVG fonts */

2010-06-20T05:53:19Z

SVG fonts

← Older revision		Revision as of 05:53, 20 June 2010
Line 64:		Line 64:
	=== SVG fonts ===		=== SVG fonts ===

	Firefox and IE ~~will~~ not add support for SVG fonts.		Firefox and IE are not working to add support for SVG fonts.

			See Firefox discussion at [https://bugzilla.mozilla.org/show_bug.cgi?id=119490 bug 119490].

			SVG2.0 may replace SVG fonts by WOFF.

			Advantages of WOFF:

			* Good for large amounts of text.
			* Support for complex scripts (Arabic, Hindi, etc.).
			* Lots of available fonts.

			Advantages of SVG fonts:

			* Good for small amounts of text.
			** Headings.
			** Logos.
			** Selectable.
			* Easy to create new designs.
			* Can animate.
			* Use to clip things like video.

	=== Filters ===		=== Filters ===

Tavmjong: /* (Fancy) paths */

2010-06-20T05:37:05Z

(Fancy) paths

← Older revision		Revision as of 05:37, 20 June 2010
Line 51:		Line 51:
	=== (Fancy) paths ===		=== (Fancy) paths ===

	* 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)		* Vector effects: [http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html SVG 1,2].
	* Patterns along paths,		* Patterns along paths.
	* Vector effects.		* Power stroke: [http://wiki.inkscape.org/wiki/index.php/PowerStroke description].
	* Power stroke.		* 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 ===		=== Gradients ===

Jaspervdg: /* Areas of Inkscape Interest */

2010-06-15T16:12:35Z

Areas of Inkscape Interest

← Older revision		Revision as of 16:12, 15 June 2010
Line 45:		Line 45:
	Creating a standard way to indicate layers. Inkscape uses private attributes.		Creating a standard way to indicate layers. Inkscape uses private attributes.

	=== ~~Fancy paths~~ ===		=== 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 ===

			* 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)
	* Patterns along paths,		* Patterns along paths,
	* Vector effects.		* Vector effects.
Line 63:		Line 68:

	*Increasing bit depth to reduce artifacts.		*Increasing bit depth to reduce artifacts.
	*Margins. (--[[User:Jaspervdg\|Jaspervdg]] 13:49, 15 June 2010 (UTC) I would prefer them not to have any attributes for margins.)		*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. (--[[User:Jaspervdg\|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).

			--[[User:Jaspervdg\|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 ===		=== Cacheable portion/layers ===

	*Investigate partial.s cache-ablity		*Investigate partial.s cache-ablity

Jaspervdg: /* Filters */

2010-06-15T13:49:26Z

Filters

← Older revision		Revision as of 13:49, 15 June 2010
Line 63:		Line 63:

	*Increasing bit depth to reduce artifacts.		*Increasing bit depth to reduce artifacts.
	*Margins.		*Margins. (--[[User:Jaspervdg\|Jaspervdg]] 13:49, 15 June 2010 (UTC) I would prefer them not to have any attributes for margins.)

	=== Cacheable portion/layers ===		=== Cacheable portion/layers ===

	*Investigate partial.s cache-ablity		*Investigate partial.s cache-ablity

Paradisaeidae: Section caching.

2010-06-15T01:29:43Z

Section caching.

← Older revision		Revision as of 01:29, 15 June 2010
Line 64:		Line 64:
	*Increasing bit depth to reduce artifacts.		*Increasing bit depth to reduce artifacts.
	*Margins.		*Margins.

			=== Cacheable portion/layers ===

			*Investigate partial.s cache-ablity

Tavmjong: /* Inkscape representitive */

2010-06-14T12:10:50Z

Inkscape representitive

← Older revision		Revision as of 12:10, 14 June 2010
Line 6:		Line 6:

	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.		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 ==		== SVG Working Group Links ==

Tavmjong: Created page with '== 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 ...'

2010-06-14T11:59:46Z

Created page with '== 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 ...'

New page

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

== SVG Working Group Links ==

=== General ===

* [http://www.w3.org/Graphics/SVG/WG/wiki/Main_Page Working Group Main Page]
* [http://lists.w3.org/Archives/Public/public-svg-wg/ Public-SVG-WG Mail Archives]
* [http://lists.w3.org/Archives/Public/www-svg/ WWW-SVG Mail Archives] (The true public mailing list).
* [http://www.w3.org/Graphics/SVG/WG/wiki/Meetings Schedule]

=== Standards ===

*[http://www.w3.org/TR/#tr_SVG Complete List]

==== Completed ====

* [http://www.w3.org/TR/2003/REC-SVG11-20030114/ SVG 1.1]
* [http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/ SVG Tiny 1.2]

==== Proposed Standards ====

*[http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap 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.

=== Fancy paths ===

* Patterns along paths,
* Vector effects.
* Power stroke.

=== Gradients ===

* Diffusion curves.
* Mesh gradients.

=== SVG fonts ===

Firefox and IE will not add support for SVG fonts.

=== Filters ===

*Increasing bit depth to reduce artifacts.
*Margins.