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

Re: marker-pattern syntax

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 26 Nov 2012 14:31:19 -0800
Message-ID: <CAAWBYDDtOj4f2F+qYY0zWpP2wvFApZ6i6NKSethHWRpL2TJg2g@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: SVG public list <www-svg@w3.org>
On Mon, Nov 26, 2012 at 2:04 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> 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:
>>> 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>?

As far as I can tell, in your suggested grammar you specify a single
marker type via url(), then a list of distances that it should iterate
between.  If you want a second type of marker, you need a separate
list.  That means that the example in the spec, which alternates
between 1 and 2-line markers, actually *cannot* be written.  It's
*almost* this:

marker-pattern: url(#SingleDash) 80px, url(#DoubleDash) 40px 80px;

...except that doesn't work, because the double-dash will now
alternate as 40px-80px-40px-80px, rather than being 80px apart with an
"initial offset" of 40px, as intended.

Even if you *could* provide an initial offset, with something like
"40px url(#DoubleDash) 80px", it's still a worse grammar.  It's not
immediately clear, from looking at it, that the intended effect is for
the two markers to alternate every 40px.  The current grammar in the
spec makes this easy to see with "40px url(#DoubleDash) 40px
url(#SingleDash)".  My suggested grammar preserves this easy
readability.


>> 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?

Instead of providing a url() at a spot to indicate a marker, you can
provide "none", which just means "no marker here, continue with what
you were doing".  This is allowed by the current grammar, and seems
reasonable for readability purposes.  (You could always just combine
the lengths on either side into a single one, but that might obscure
some useful symmetries.)


>> 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.

I answered this above.


>> 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 have no idea what you mean.  My exact words is that it would work
nicely with the 'marker' shorthand *I suggested*, not the current
spec's shorthand grammar.


> 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.

Yeah, an offset seems necessary for your proposal.  I suggested such
above before I read down this far.  ^_^  However, I think sticking
closer to the current spec's grammar removes the need for an offset,
right?

~TJ
Received on Monday, 26 November 2012 22:32:06 GMT

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