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

Re: marker-pattern syntax

From: Dirk Schulze <dschulze@adobe.com>
Date: Tue, 27 Nov 2012 21:08:53 -0800
To: Cameron McCormack <cam@mcc.id.au>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, SVG public list <www-svg@w3.org>
Message-ID: <3C519AEC-FEAC-4242-9172-CE675258F0D1@adobe.com>

On Nov 27, 2012, at 8:50 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> Dirk Schulze:
>> No, this syntax seems by far to complex to implement. (Note that implementing repeating patterns is very calculation insensitive anyway.)
>> 
>> 10px url() 20px 40% repeat(url() 20px 20px 10% url()) 20px
>> 
>> What does this mean?
>> 
>> Please keep it simple
> 
> I think it's pretty simple to interpret.  You repeat the "url() 20px 
> 20px 10% url()" within the
> 
>   pathLength - 10px - 20px - 40% - 20px
> 
> section in the middle of the path.
> 
> What would be more difficult to interpret was if you had multiple 
> repeat() values, but I would think you'd only only one.

This would not be a good idea, and we just can support one repeat. But why should authors just differ with different markers at the beginning and the end of the path? Why shouldn't they want to have special value in the middle and everything around repeats? This gets ridiculous complicated. Let us concentrate on basic functionality. Something that you would expect from a pattern: it repeats.

> 
> I think if we want to allow at least an offset at the start, then we 
> should also allow one at the end.  Extending that to support arbitrary 
> start/end patterns like the above is kind of neat, although if you don't 
> care about painting order, you could achieve it by just adding 
> additional tracks.
> 
>> <distance> with a <url> defines a pattern. Another proposal would go into the same directions as Tab's proposal:
>> 
>> [   [<url> <distance>*]+ [no-repeat | repeat]?   ]#
>> 
>> Each distance after a url describes the offset for the current marker:
>> 
>> 	url(#m1) 20px;
>> 
>> would be:
>> 
>> 	--#--#
>> 
>> and
>> 
>> 	url(#m1) 20px no-repeat;
>> 
>> would be:
>> 
>> 	--#---------
>> 
>> with no-repeat It would not repeat. A url without a distance has an offset of 0:
>> 
>> 	url(#m1) 20px url(#m2) url(#m1) 20px 30px
>> 
>> would be
>> 
>> 	--#/O--#---#--#/O--#---#.
>> 
>> #/O means both markers are drawn at the same position.
> 
> I think I much prefer the length to go before the marker url(), as I 
> think of processing the pattern from left to right: if it's a length, 
> advance the current position by that length; if it's a url(), draw a 
> marker at the current position.
> 
>> The advantage is that you always know which offset belongs to which url. It may not be so clear from the beginning with Tabs proposal that 20px url(#m1) 20px 20px 30px url(#m2) is the same as 20px url(#m1) 20px url(#m1) 20px url(#m1) 30px url(#m2). If no keyword repeat or no-repeat is used, then it is the same as no-repeat.
> 
> I didn't realise that about Tab's proposal (if it is actually the case), 
> that the url()s are implied between each length.  I assumed it was like 
> in the current spec text, where consecutive lengths just keep advancing 
> the current position.

No, he explained that this would be possible with calc(). We don't need to invent the wheel again. If you want 20% + 10px then do calc(20% + 10px).

I think this makes clear what he wanted:

>>        marker-pattern: path 10px url(#m1) 20px url(#m2) 50px;
>>        -#--#-----O--#-----O--#.
>> 
>>        marker-pattern: path 10px url(#m1) 20px url(#m2) 50px 10px;
>>        -#--#-----O-O--#-----O-O--#.
> 
> These last two aren't right.  They should be, respectively:
> 
> -#--O-----#--O-----#--O---...
> 
> -#--O-----O-#--O-----O-#--O---

Here it seems the first distance is the offset of the pattern, the last distance the gap after the pattern sequence. Two distance after each other imply that there is the previous url between them.

Greetings,
Dirk
Received on Wednesday, 28 November 2012 05:09:26 GMT

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