Re: Feature request for SVG2 : stroke-position

I like the idea of stroke-position. I believe it covers most needs of web developers, it is easy to implement and doesn't cause multiple DOM calls like vector-effect does.

stroke-fraction is maybe a bit to complicated in my eyes. How does it work together with stroke-width? If it takes stroke width into account, what if the width doesn't reach the outermost border defined by stroke-fraction? This would have a better place in vector-effects.

Again, stroke-position wouldn't replace vector-effects. But I believe it is a good idea to have it beside vector-effects.

Dirk


Am 20.09.2011 um 11:55 schrieb Dr. Olaf Hoffmann:

> 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:
> http://hoffmann.bplaced.net/svgueb/klippklapp05.svg
> http://hoffmann.bplaced.net/svgueb/klippklapp07.svg
> 
> 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. 
> 
> Olaf
> 
> 
> 
> 
>

Received on Sunday, 2 October 2011 06:53:46 UTC