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 ;)
> 2) 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.
> 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.
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.
> 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.
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