Re: marker improvements

Cyril Concolato:
> Some additional comments. This is my first real reading of the marker
> section, so some of my comments might be not-acceptable given the legacy
> 1.1 behavior.
>
> * In the first sentence of 11.6: "A marker is a symbol ...". I think we
> could change the word 'symbol' (to something like 'graphics') as this is
> not necessarily refering to a <symbol> element. This is confusing.

I've replaced it with  "graphical object".

> * I don't understand ISSUE 2. What do you mean by "setting back" ?

By setting back I meant moving the two endpoints of the path around the 
marker position, but perhaps "setting back" is the wrong term (sounds 
like offsetting).  In any case, I've removed this issue since I already 
have the stroke knockout section in there now.

> * In the marker-segment definition, you say that a marker is added to
> non-zero length path segment. It's creating a special case for
> zero-length segment. This can produce a weird effect when animating a
> path segment when the length goes from non-zero to zero to non-zero,
> where the marker would disappear (blink). I don't know how frequent this
> case would be though.

Good point.  I figured that you would rarely want to see the marker in 
this case, but you are right that if you're animating the path then the 
markers would slowly overlap until they are coincident and then one 
would disappear.  I've removed the word "non-zero" from that section.

> * The description of marker-mid still says 'or at the center of every
> path segment'. Is this normal?

No, removed.

> * When giving the drawing order between all types of marker "Markers on
> a given element are painted in the following order:", it is not clear
> which type is on top. It would clearer to say that the painter's
> algorithm is used or to say that they are "painted on top of each other
> in the following order".

I've made that introductory sentence:

   Markers on a given element are painted in the following order, from
   bottom to top:

> * "... marker is to be fitted when it is rendered ... ": It should
> probably say 'fitted according to the viewBox and preserveAspectRatio
> attributes'.

OK.

> * "the reference point of the marker which is to be aligned": it's weird
> to say 'aligned' for a point. I'd say 'positioned'.

I've gone with "placed" since the sentence uses "position" later.

> * "orient": It is not clear from this section if the rotation performed
> before the fitting or after? It is clearer looking at 11.6.7. You might
> want to put a link to that section.

Done.

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

> * It's probably worth starting a new line for "If the marker is on the
> first or last vertex".

OK.

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

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

I thought that was just for existing xlink:href attributes.

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

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

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

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

> * pattern:
> You wouldn't allow marker-pattern="#marker1 10px none 20px #marker2" ?
> I know you can write marker-pattern="#marker1 30px #marker2"
> but it might be useful for animation of the second marker:
> marker-pattern="#marker1 10px #newmarker 20px #marker2"
> Actually, you can already do that by putting an invalid marker reference
> but I think it's better to put none.

OK, fair enough, I've allowed this now.

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

> * "[ none | <funciri> ]{4} / <‘marker-pattern’>" you probably want to
> write {1,4}.

Good catch.

> * The initial value of the marker-knockout properties is defined as
> none, but this is not an allowed value. What does it mean?

It means I made a mistake. :)  I changed it to 0.

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

> That's it for now.

Thanks for the comments!

Received on Friday, 1 June 2012 08:44:38 UTC