W3C home > Mailing lists > Public > www-svg@w3.org > November 2012

Re: 'marker-segment' and distance + 'marker-pattern' + 'marker'

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 26 Nov 2012 13:56:52 -0800
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: SVG public list <www-svg@w3.org>
Message-ID: <159E38E4-1B8E-4517-9DEA-484B940F5351@adobe.com>

On Nov 26, 2012, at 11:10 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Nov 22, 2012 at 7:37 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Hi SVG WG,
>> 
>> I think 'marker-segment' should have the same syntax as 'marker-pattern' and allow a distance. Often you want to position markers on the corners of a path (even the example for marker-segement does it for demonstration ;)).
> 
> Isn't this what marker-start/end/mid is for?  marker-segment is just a
> fourth member of that family, for putting things in the center.
> 
>> <percentage> would be relative to the segment length, <length> is a distance from the start of a segment.
>> 
>>        marker-segment: none | [ <url> <distance>+ ]+
>> 
>> Multiple markers on the same position should be possible. This can have some neat affects. Markers are drawn by the order. First all markers of the first sequence, then all markers of the next sequence and so on. It must be clarified what happens with negative values.
> 
> However, this seems reasonable to me.  If you're putting them on a
> segment, rather than a vertex, choosing the center is a logical
> default, but still an arbitrary choice.  Allowing authors the ability
> to position their markers anywhere along the segment is a good idea.
> 
> If at all possible, the syntax should be comma-separated, though.
> Having pairs of things without a delimiter is confusing to read.  We'd
> just have to make sure that's not troublesome in the shorthand.

I am not only suggesting a positioning of one marker, but a pattern dependent on the marker. Each segment could have a marker that is like this:

	-|---|

This would be repeated from the start of each segment till the end. If you just want to have a marker per segment in the middle, you would do

	marker-segment: url(#marker) 50%;

But if you want to have something like marker-pattern per segment, you do something like this:

	marker-segment: url(#marker) 10px 30px;

And even allow multiple markers:

	marker-segment: url(#marker1) 20px url(#marker2) 30px;


> 
> 
>> This would cause problems with the shorthand 'marker'. But the current syntax is not valid for shorthands anyway. To solve this problem, I would suggest the following syntax:
>> 
>>        marker: <marker-tripple> [, <marker-pattern>[, <marker-segment>] ]
>>        marker-pattern: <marker-pattern>
>>        marker-segment: <marker-segment>
>> 
>> with:
>>        <marker-tripple> = [none | <url>]{1,3} - marker-start, marker-middle and marker-end as in SVG 1.1. If a url is missing, the value gets resolved to none.
>>        <marker-segment> = none | [<url> <distance>+]+
>>        <pattern-segment> = none | [<url> <distance>+]+
>>        <distance> = <length> | <percentage>
>> 
>> If you want to specify just segments with the shorthand instead of 'marker-segment', you would need to do: "none, none, url(#marker) 20% url(#marker2) 40%". But I think this is reasonable. The shorthand is just useful if you want to specify more then one marker solution (combination of pattern and segment).
> 
> Alternately, and perhaps more understandably, adopt more explicit
> delimiters, like:
> 
> marker: [start <url>] || [mid <url>] || [end <url>] || [ segment [
> <url> <distance>+ ]# ] || [pattern <'marker-pattern'>] | <url> | none;
> 
> Possibly allow start/mid/end to be collapsed together, so you can say
> "marker: start end url(...) mid url(...);".  I don't really want to
> write out the necessary grammar for that right now.

We need to be consistent with the old marker syntax, which is still used very often. That means, one part is always:

	none | <url>{1,3}

And represent marker-start, mid and end. That is why the syntax proposed above doesn't work.

Greetings,
Dirk

> 
> ~TJ
Received on Monday, 26 November 2012 21:57:17 GMT

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