W3C home > Mailing lists > Public > www-svg@w3.org > September 2011

Re: Feature request for SVG2 : stroke-position

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Tue, 20 Sep 2011 11:55:56 +0200
To: Jeremie Patonnier <jeremie.patonnier@gmail.com>, www-svg@w3.org
Message-Id: <201109201155.57037.Dr.O.Hoffmann@gmx.de>
Jeremie Patonnier:
> >
> > obviously this would be much simpler than to reuse elements or entities
> > of path fragments with clipping or masking as currently or using the
> > vector effect draft for this (as far as I understand it, it could cover
> > this as well, but not simpler than clipping or masking:
> >
> > http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer
> >.html
> > http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html
> Yes, Vector effects are great but are much harder to use to achieve simple
> stroke manipulation.

Indeed, therefore I agree, that it would be useful to have a simpler option
additionally to vector effects and clipping, masking and filters for such a 
specific effect, required for several applications.

> > But it is maybe a better (?) alternative to display only a fraction of
> > the stroke using for example something like stroke-fraction="0.3,0.1",
> > default would be stroke-fraction="0.5,0.5"?
> > This would indicate, which part perpendicular to the path direction
> > is intended to be displayed, for example the first parameter for
> > the fraction outside of fill or if there is no fill and second
> > within/above fill.
> Yes, this is a powerfull tool, but in some way having two values to
> manipulate is harder for (dumb) authors than one.

Well, you will have parts on a possibly filled area and parts
outside of it, therefore two parameters will typically clarify, what the
intended effect for a more complex path is. 
And for example for stroke-dasharray you have a list and this is
not difficult to understand as well for for transform you have
two parameters for translation, one to three for rotation.

> Discussion around how things work with two values can be extremely
> difficult (as a little sample : What happen with stroke-fraction="0.3,0.1",
> where the 0.6 missing part goes ? Is it truncated ? Is it balanced ?)
> Having a single value that move the rendering points sounds easier to
> understand for authors (but not necessary easier to implement)

The name of the property indicates already, that only a part of the
stroke is displayed, the other fraction is clipped.
You can write for example stroke-fraction="0.4,-0.1" to get only
30% of the width displayed with some offset from the path itself.
If stroke-width="100" this means, the absolute width of the displayed 
fraction will be 30 and the offset is 10 (at least in areas, where the
shape has both inside and outside of the possibly filled area).

If you have for example 
<path d="M0,0 1000,0" stroke-width="100" stroke-position="10" />
it is not obvious, what to do with is, as already mentioned.
Because stroke-fraction is defined to be equivalent to some
clipping, there is always a defined display.
Of course, one can define stroke-position as well to be equivalent
to some clipping effect, in this case it is only more difficult to
determine the 'width' before clipping from the given information,
therefore maybe more difficult to implement, but should be solvable
too, of course.

Years ago I wrote already a tutorial (in german) about the problem
how to use clip, mask, filter etc to display only a part of the stroke
including animation of such a fraction, examples:

Of course, one can use another parametrisation as well.
I think, if the problem can be reduced to some kind of clipping
problem, it is quite simple to implement, because typically
clipping is already available, implemented in viewers.
Therefore however the property is called, if the effect
is reduced to clipping of parts of the stroke, it should cause
no new problems for implementors (hopefully), what 
increases the chance, that is can be implemented easier
and faster ;o)

> > Another alternative could be to combine this with the idea of
> > a stroke with different widths, than stroke-fraction would be a
> > longer list or better two attributes, each one list, one above fill,
> > one outside. And there will be a need for stroke-keys and stroke-splines
> > to get the shape of the stroke similar to keyTimes and keySplines for
> > animation.
> Maybe but in such a situation, this feature will become to complex for
> author that will fallback on simpler tools such as... let's say Vector
> Effects ? ;)

No, not really, if you need no change of the width, you provide only
one pair of parameters.
Constant width:  
 stroke-fraction-inside="0.2" stroke-fraction-outside="0.4"
Different width: 
 stroke-fraction-inside="0,0.5,0.2" stroke-fraction-outside="0.5,0,0.1"

> The purpose of my proposal is to provide simple tools for authors (in that
> case to simply act on stroke). 

This is my intention as well, but such features are much more useful, if
authors can start with a simple value and have the option to get step
by step more options by added additional values. If you don't need
them, you don't have to care, if you need an advanced effect, there is
not much to learn to get it with the things, you already know.

> At some points, it's very hard to produce 
> SVG by hand and I think SVG needs more simple tools (even if they are
> limited) thought for authors (in addition of amazing power tools thought
> for editors of course).

Sure, I create almost all of my SVG or scripts generating SVG output with
a simple text editor. And I like to start with simple things, exploring step 
by step, what one can do with them to get more interesting results.
And of course, because I have already a lot of documents and implementations
are typically all incomplete, I prefer a feature construction, that is somehow
backwards compatible, what means for new features, that you still have some
more or meaningful display, if the viewer does not know the new feature,
or if the new feature is implemented, that this does not cause changes to
older documents. 

Received on Tuesday, 20 September 2011 09:56:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT