Re: marker improvements

Hi Cameron,

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 don't understand ISSUE 2. What do you mean by "setting back" ?

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

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

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

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

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

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

* What is the incoming and outgoing direction for the center of a path 
segment? How can they be different?

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

* For ISSUE-4, we could also say that the position is computed modulo 
the path length.

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

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

* ISSUE-7: why do you want to special case the positioned marker?

* Figure 9: I don't see the circle and cross markers in the image. Is 
this normal?

* What does " <funciri> values made absolute" ? absolute as "base URL + 
path in the document" ? Shouldn't we that IRI are transformed into IRI 
relative to the root element?

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

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

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

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

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

That's it for now.

Cyril


----- Mail original -----
De: "Cameron McCormack" <cam@mcc.id.au>
À: "SVG public list" <www-svg@w3.org>
Envoyé: Samedi 26 Mai 2012 09:26:54
Objet: marker improvements

I've added some of the marker improvement proposals that we discussed 
recently to the spec, although I have changed them a bit.  Instead of 
extending marker-mid to allow specifying a pattern of markers to place 
along the path, not at vertices, I added a separate property for this. I 
also added a separate property for markers at the centre of path 
segments.  marker-start, marker-mid and marker-end remain unchanged.

marker-segment:

    https://svgwg.org/svg2-draft/painting.html#SegmentMarkers

marker-pattern:

    https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers

The expanded marker shorthand that allows setting marker-{start,mid,
end,segment,pattern} at once, with different values:

    https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers

There's some updated text at the start of the section with an overview 
of the different types of markers:

    https://svgwg.org/svg2-draft/painting.html#Markers

I extended the <marker> element like we discussed to allow it as a child 
of a <path> etc. element.  That's a "positioned marker".


For setting back the stroke to allow better arrowheads, and to have say 
circular hollow markers without the stroke showing through, I added a 
half baked proposal to stimulate some discussion:

    https://svgwg.org/svg2-draft/painting.html#MarkerKnockout

Look at the image for an overview without having to read all that dense 
text in there.

I went a bit crazy on the shapes, perhaps, but the key thing I was 
trying to avoid was allowing a generic path to be specified, since that 
would require some difficult intersection checking.  At least with these 
predefined shapes the number of edges to check for intersections is low 
and known.

But as I mention in the ISSUE in that section, using this feature for 
some cooler looking dash patterns (dashes looking like chevrons for 
example) you probably want to put the two sides of the shape at 
different orientations along the path, and that again requires more 
difficult shape/intersection calculations.

Anyway, comments welcome.

Received on Friday, 1 June 2012 07:27:43 UTC