Hi,
The SVG working group is going through a rather long list of things proposed for 2.0. The list can be found at:
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
The WG is about halfway through the list. If you have strong feelings on any of the proposed additions, please let me know ASAP. The group will continue working through the list this Thursday and Friday.
Tav
1) ISSUE 2271: Variable Stroke Width
I notice that Variable Stroke Width has been given a "yes", which is great, but Randomization has been given a "no". It would be good to allow some randomisation in the syntax for the variable stroke width, to simulate a hand drawn look.
I'm assuming from the notes that variable stroke width is likely to be implemented something like this, where the variable widths are evenly spaced along the path:
<path d="..." stroke-width="0,3,10,2.5,0" />
I'd like to see a syntax to allow those stroke widths to be randomised by +/- a defined amount:
<path d="..." stroke-width="0,3,rand(10,2),rand(2.5,0.5),0" />
So the first, second and last widths are fixed, but the third and fourth are randomised as 10+/-2 and 2.5+/-0.5. For elements that are re-used, the randomisation would be recalculated for each use so that "identical" paths each have a slightly different look to them (there might be a need for this to be optional - I can see uses where a randomised path would need to keep the same widths when re-used elsewhere).
Doing this declaratively is a lot easier than writing some JS to handle it.
2) Alternative Transformations
I notice you've already mentioned that Inkscape users would like perspective transformations. I strongly agree with that position - it's one of the things that causes me the most problems when trying to draw my SVG comics. For signage in the strips, in particular, I'd love to be able to use a perspective transform on the text, but still have it as text in the SVG (rather than converting to a path and manipulating the nodes).
This would simplify some other use cases, such as re-using a door in multiple panels using perspective transforms to make it seem to "open" (or, indeed, for animating the same effect in a single image).
3) Enhanced Text Support
I am strongly in favour of David Dailey's proposal to allow text to be manipulated and squished into convex polygons. This would solve many of the requirements I have for perspective transformations (though not all of them), and would let SVG produce a wide variety of artistic/design effects that it's not currently suited to.
4) Basic SVG UI enhancements
I strongly agree with the need for viewers to provide a default zoom-and-pan widget. There should be a way for the author to indicate a preference for it appearing or not, and for the user to override that preference. Without an easy way to pan and zoom, the S and V in SVG don't mean much.
5) ISSUE-2354: Consider adding a 'inverse' value to clip-rule
I'm strongly in favour of this.
Regards,
Mark
On Wed, Nov 2, 2011 at 9:02 PM, Tavmjong Bah <tavmjong@...206...> wrote:
Hi,
The SVG working group is going through a rather long list of thingsproposed for 2.0. The list can be found at:
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_InputThe WG is about halfway through the list. If you have strong feelings on any of the proposed additions, please let me know ASAP. The group will continue working through the list this Thursday and Friday.
Tav
Thanks for your input!
On Thu, 2011-11-03 at 11:00 +0000, Mark Crutch wrote:
- ISSUE 2271: Variable Stroke Width
I notice that Variable Stroke Width has been given a "yes", which is great, but Randomization has been given a "no". It would be good to allow some randomisation in the syntax for the variable stroke width, to simulate a hand drawn look.
I'm assuming from the notes that variable stroke width is likely to be implemented something like this, where the variable widths are evenly spaced along the path:
<path d="..." stroke-width="0,3,10,2.5,0" />
I'd like to see a syntax to allow those stroke widths to be randomised by +/- a defined amount:
<path d="..." stroke-width="0,3,rand(10,2),rand(2.5,0.5),0" />
So the first, second and last widths are fixed, but the third and fourth are randomised as 10+/-2 and 2.5+/-0.5. For elements that are re-used, the randomisation would be recalculated for each use so that "identical" paths each have a slightly different look to them (there might be a need for this to be optional - I can see uses where a randomised path would need to keep the same widths when re-used elsewhere).
Doing this declaratively is a lot easier than writing some JS to handle it.
I'll mention this during a WG meeting. Note, the randomization would have to be a pseudo-randomization, much like what is done for the turbulence filter, so that the drawing would be the same in different SVG renders. Different "identical" paths could by made to look different by setting a different seed.
- Alternative Transformations
I notice you've already mentioned that Inkscape users would like perspective transformations. I strongly agree with that position - it's one of the things that causes me the most problems when trying to draw my SVG comics. For signage in the strips, in particular, I'd love to be able to use a perspective transform on the text, but still have it as text in the SVG (rather than converting to a path and manipulating the nodes).
This would simplify some other use cases, such as re-using a door in multiple panels using perspective transforms to make it seem to "open" (or, indeed, for animating the same effect in a single image).
This should be doable by CSS Transformations which SVG will use. See:
http://www.w3.org/TR/css3-3d-transforms/
For demos, see:
http://css3.bradshawenterprises.com/all/
- Enhanced Text Support
I am strongly in favour of David Dailey's proposal to allow text to be manipulated and squished into convex polygons. This would solve many of the requirements I have for perspective transformations (though not all of them), and would let SVG produce a wide variety of artistic/design effects that it's not currently suited to.
I'm not sure this is going to fly. There is strong interest in the group for additional means of manipulating text but this may not be the answer.
- Basic SVG UI enhancements
I strongly agree with the need for viewers to provide a default zoom-and-pan widget. There should be a way for the author to indicate a preference for it appearing or not, and for the user to override that preference. Without an easy way to pan and zoom, the S and V in SVG don't mean much.
I think the WG will think this is more of a browser issue. However, things like currenScale, currentTranslate could be added to make it easier for browsers to do this.
- ISSUE-2354: Consider adding a 'inverse' value to clip-rule
I'm strongly in favour of this.
Noted.
On Thu, Nov 3, 2011 at 1:59 PM, Tavmjong Bah <tavmjong@...206...> wrote:
I'll mention this during a WG meeting. Note, the randomization would have to be a pseudo-randomization, much like what is done for the turbulence filter, so that the drawing would be the same in different SVG renders. Different "identical" paths could by made to look different by setting a different seed.
A pseudo-random approach certainly makes sense.
At the point at which a syntax for the path-width array is discussed, here are a few other suggestions that may be worth considering:
* A means to vary the positions of the width stops, other than having them evenly spaced along the path. Some randomisation here would also be useful when creating a hand drawn look.
* A means to tersely create repeated sequences of widths - this will be most useful for long paths with lots of width stops. E.g something like:
<path d="..." stroke-width="0,3, repeat(100, [10,2.5]), 0" /> <path d="..." stroke-width="0,3, repeat(100, [rand(10,2),rand(2.5,0.5)]), 0" />
These would create a series of 200 widths (100 repetitions of a sequence of two values), alternating between 10 and 2.5 in the first case, 10+/-2 and 2.5+/-0.5 in the second case.
* A means to define the transition path between width stops - linear, ease-in, ease-out, etc. I could see some validity in being able to define these separately for each side of the path, defaulting to the same values for both sides if only a single set of values is specified, though that might be over complicating things.
* A means to asymmetrically offset the widths relative to the skeleton path - i.e. I may want my width to be 10 units, but distributed as 8 on one side of the path and 2 on the other.
Goodness knows how all these possibilities would come together into one coherent set of attributes, though - I'm glad I'm not writing the spec ;)
- Alternative Transformations
This should be doable by CSS Transformations which SVG will use. See:
I hadn't realised that SVG2.0 was going to use CSS Transformations. Yes, that would certainly fulfil most of my requirements.
- Enhanced Text Support
I am strongly in favour of David Dailey's proposal to allow text to be manipulated and squished into convex polygons. This would solve many of the requirements I have for perspective transformations (though not all of them), and would let SVG produce a wide variety of artistic/design effects that it's not currently suited to.
I'm not sure this is going to fly. There is strong interest in the group for additional means of manipulating text but this may not be the answer.
Just to clarify, it's not necessarily the specifics of David Dailey's proposal that I favour, so much as the general idea of being able to artistically manipulate text, yet still have it exist as text in the DOM, with all the flexibility and scripting opportunity that implies. It's good to know that there is interest in this area from within the group.
- Basic SVG UI enhancements
I strongly agree with the need for viewers to provide a default zoom-and-pan widget. There should be a way for the author to indicate a preference for it appearing or not, and for the user to override that preference. Without an easy way to pan and zoom, the S and V in SVG don't mean much.
I think the WG will think this is more of a browser issue. However, things like currenScale, currentTranslate could be added to make it easier for browsers to do this.
I agree that implementation is definitely a browser issue, and the WG shouldn't be enforcing any particular UI for this feature. I would like to see the WG recommend that user agents provide a zoom-and-pan facility, however, as such a recommendation provides greater leverage when filing a feature request.
Associated with such a recommendation would also a means to allow the author to suggest that the UI is disabled by default - for those cases where they would prefer to supply their own solution. E.g. a nativeZoomAndPan="false" attribute on the root element, or something similar.
Many thanks for asking for our input on this list. It's great to have the opportunity to make suggestions about something so fundamental to both Inkscape and the web at large, despite just being a "user".
Mark
The SVG working group is going through a rather long list of things proposed for 2.0. The list can be found at:
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
I read through the page and did not see anything specific to preserving local coordinate systems - is that something planned? It is already supported in the rendering and the SVG spec by some degree through viewports as I mentioned here: http://old.nabble.com/Local-Coordinates-for-group-transformations--td2653578...
It would be nice to see something similar for group. Being able to preserve orthagonality/shearing, etc in a transformed group would be very useful...
Thanks-
-Rob A>
participants (3)
-
Mark Crutch -
Rob Antonishen -
Tavmjong Bah