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

Re: marker-pattern syntax

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 26 Nov 2012 14:04:39 -0800
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: SVG public list <www-svg@w3.org>
Message-ID: <99DEAF6A-AC07-418F-8C60-AF3596201781@adobe.com>

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

> On Thu, Nov 22, 2012 at 6:44 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> 
>> On Nov 21, 2012, at 10:54 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> 
>>> Hi SVG folks,
>>> 
>>> Just looked at the syntax of maker-pattern and think that there is a mistake[1]:
>>> 
>>>      [ none | <length> | <percentage> | <funciri> ]+
>>> 
>>> "A bar (|) separates two or more alternatives: exactly one of them must occur."[2]
>>> 
>>> Means that just one in the list can occur, which is may or may not be correct.
>>> 
>>> <percentage>,<length> "Indicates the length of a gap in the repeated pattern of markers."
>>> 
>>> In this case it seems correct. But looking at the example, the values do not define the length of a gap but the distance between two markers (which makes more sense IMO). But in this case the syntax is wrong (and the wording can be improved). It depends on the needs of 'marker' shorthand, but I have two syntax proposals:
>>> 
>>>      none | [ <funciri> || [<length> | <percentage>] ]#
>>> 
>>> or
>>> 
>>>      none | [ <funciri> [<length> | <percentage>] ]#
>> 
>> To get back to it: sometimes you want a marker follow a pseudo irregular pattern. It should be possible to define multiple distances:
>> 
>>        marker-pattern: url(#marker1) 20px 40px, url(#marker2) 20% 40px;
>> 
>> The first marker pattern draws a marker after 20px, then after 40px from the first marker position, then after 20px of the second marker position and so on. Same for the second marker pattern. That is why I  would suggest the following change now :)
>> 
>>        marker-pattern: none | [ <url> <distance>+ ]#
> 
> I think the additional ability offered by setting multiple lists in
> marker-pattern is potentially useful, but I don't like the
> simplification you've made to each individual list.  You can no longer
> easily swap between two different markers (you have to instead
> coordinate two separate distance lists), nor can you easily insert
> "gaps" in the marker list (you have to instead lengthen the distance).

Can you give an example? I don't get your point. Where is the problem with "url(..) 20px 30px url() 20%"? Why can't you see the two different lists per <url>?

> 
> We can merge them together reasonably, though:
> 
> <distance> = <length> | <percentage>;

yes

> <marker-instance> = none | <url>;

yes

> marker-pattern: [ <distance>? <marker-instance> [ <distance>
> <marker-instance>? ]* ]#
> 
> This lets you still intersperse multiple markers (or gaps) in a single
> run, but also lets you specify multiple independent runs.

What do you mean with gap? I don't understand your <distance> at the beginning?

> 
> I've included your optimization that you can omit the <single-marker>,
> meaning "use the last <single-marker> provided".  This is a change
> from what the current spec seems to mean by having multiple lengths,
> which I think is just "combine them", but that's an insignificant loss
> in the modern age of calc().

Has nothing to do with calc(). I am speaking about partly regular returning patterns. See the example here:

--|-----|-|--|-----|-|--|.

This is just possible with different distances.


> 
> This plays nicely with the 'marker' shorthand that I suggested in the
> other thread, where you prefix each segment of the shorthand with an
> ident for the subproperty it's specifying.

It does not, since your example doesn't work with the current syntax. I also have an addition to my syntax. I would like to define an offset for a returning pattern, like for stroke-dasharray:

	<marker-instance> <distance>+ [/ <distance>]?

where the last distance, separated by a '/', is the offset of this pattern.

Greetings,
Dirk

> 
> ~TJ
Received on Monday, 26 November 2012 22:05:14 GMT

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