Re: marker improvements

Regarding the zero-length line and markers issue. I asked about this some
time back, and understood the target behavior to be as follows ...

1. Isolated moveTo segments generate both a marker-begin and marker-end at
each move location. e.g. M 10 10 m 10 10 m 10 10 would produce both
marker-begin and marker-end at (10,10), (20,20) and (30,30). The use case
for this is scatter plot drawing, but it seems the positioned marker spec
handles that case now, so I suggest we draw no markers for isolated moves.

2. Zero-length segments, including move-close and move-line, generate
marker-begin and marker-end. A zero-length move-line-close should generate
begin, mid and end markers at the location. My understanding of the
discussion thus far is that everyone agrees on this. The
animate-to-zero-length use-case is a compelling one.

Could the spec please provide these explicit cases? It would clarify things
no end.

Stephen.

On Fri, Jun 1, 2012 at 5:31 AM, Cyril Concolato <
cyril.concolato@telecom-paristech.fr> wrote:

> Hi Cameron,
>
> Thanks for the quick reply and for having done most changes. See some more
> comments inline.
>
> Le 6/1/2012 10:43 AM, Cameron McCormack a écrit :
>
>
>>  * What is the incoming and outgoing direction for the center of a path
>>> segment? How can they be different?
>>>
>>
>> If it's a Bézier with a cusp.
>>
> Ah, yes. I hadn't thought about it. Maybe worth mentioning it in the spec.
>
>
>
>>  * For ISSUE-4, we could also say that the position is computed modulo
>>> the path length.
>>>
>>
>> I don't think we should do this, since other "distance along a path"
>> things don't do this (like x position of a glyph along a text path).
>>
> I agree we should have a consistent handling of path offset.
>
>
>
>>  * about href: I thought the resolution was to keep both xlink:href and
>>> href and say that href has precedence (see
>>> http://www.w3.org/Graphics/**SVG/WG/wiki/SVG2_Resolutions#**
>>> Drop_xlink_prefix_for_href<http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#Drop_xlink_prefix_for_href>).
>>>
>>>
>>
>> I thought that was just for existing xlink:href attributes.
>>
> Oh, I had not realized that this was a new thing. I agree.
>
>
>
>>  * "Properties inherit into the ‘marker’ element from its ancestors;
>>> properties do not inherit from the element referencing the ‘marker’
>>> element.": I think it should be the opposite. In terms of
>>> implementation, I think it is easier. In terms of authoring, if you
>>> don't want inheritance to apply, specify non-inherit values on the
>>> element.
>>>
>>
>> I thought this is something that we'd discussed before and come to the
>> conclusion that we don't want to do this.  To handle the situation where
>> you want marker style to match the path, the new paint keywords will let
>> you do this.
>>
> Now that you say so, I vaguely remember that we'd discussed this before.
> Sorry for the repetition. In general, I'm not a big fan of having to
> inherit from a different place in the tree that the place of use (as it
> requires to store or compute multiple inheritance contexts per element).
> For gradient for instance this is less of a problem as meaningful
> properties (stop-*) are not inherited by default. But this is not true for
> patterns unfortunately. Could we make the marker-* not inherit by default?
>
> BTW, I just noticed that the 'inherit' keyword has been removed from all
> property descriptions. I assume that it says somewhere that all properties
> can take the value inherit even if not written in the description, right?
> Is it to align with the CSS way of defining properties? I think it's less
> readable.
>
>
>
>>  * ISSUE-7: why do you want to special case the positioned marker?
>>>
>>
>> Because there is a child element to dispatch the event to.  If we wanted
>> to allow events to be dispatched to vertex/segment/repeating markers, then
>> we'd need to add something like the SVGElementInstance tree that <use> has
>> but which we've decided to get rid of.
>>
>> Also we decided to add some DOM methods to allow authors to detect
>> interaction on vertex/segment/repeating markers when the event is
>> dispatched to the path.
>>
> Fine.
>
>
>
>>  * Figure 9: I don't see the circle and cross markers in the image. Is
>>> this normal?
>>>
>>
>> The document does:
>>
>> <path d="M x,y" marker-start="..."/>
>>
>> so I guess that's a bug, since a marker should be rendered on such paths.
>>  I'll change it though to have an invisible, non-zero length stroke to
>> avoid this.
>>
> I'm not following you here but I'll wait for the change.
>
>
>
>>  * What does " <funciri> values made absolute" ? absolute as "base URL +
>>> path in the document" ?
>>>
>>
>> Yes.  (I just used the wording Tab suggested.)
>>
>>  Shouldn't we that IRI are transformed into IRI
>>> relative to the root element?
>>>
>>
>> In CSS <uri> values always compute to an absolute URI, so I think we
>> should do the same for our <iri>s.
>>
> Fine.
>
>
>
>>  "If a value other than none is given, and the sum of the <length>s and
>>> <percentage>s is not positive, then it is an invalid value."
>>> Why not say that the lengths and percentages shall all be positive? You
>>> want to allow going backwards in the positioning of the markers? Do you
>>> have an example?
>>>
>>
>> Yes I want to allow negative values.  It'll let you write things like
>> marker-pattern="25% -10px url(#m1) 20px url(#m2) -10px".
>>
> Is it "25% -10px" or "calc(25% -10px)" ? Does it make sense to have 2
> consecutive gaps?  I don't think it's allowed in stroke-dasharray for
> instance.
>
> Regarding the last "-10px", the effect is to shift backwards the next
> occurence of the repetition pattern, so there will be some overlap between
> two patterns. I can't imagine how it is used, what is the desired effect
> and why you couldn't shift the last marker(s) forward (ie. bring it(them)
> at the beginning of the pattern) unless you want the first pattern to be
> different. Is it really the use case?
>
>
>
>>  * Figure 14: The fact that you changed both the paint order and the
>>> stroke width is confusing I think. It does not show the effect of the
>>> paint order only.
>>>
>>
>> True, but the values chosen there result in the same visible stroke width.
>>
> I think you shouln't need that to do that effect. The paint-order should
> probably be used to control the rendering when the opacity of the fill and
> stroke are different, to select which one goes on top. I'm not even sure
> it's useful for fill/stroke. To do the effect you want, you probably should
> change the position of the stroke (stroke-position="inside",
> http://www.w3.org/Graphics/**SVG/WG/wiki/Proposals/Stroke_**position<http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position>),
> no?
>
> Cyril
>
>
>