W3C home > Mailing lists > Public > www-svg@w3.org > October 2013

Re: Number of vertices unclear, when using closepath command

From: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
Date: Thu, 31 Oct 2013 15:45:09 -0500
Message-ID: <5272C155.9020705@hccnet.nl>
To: www-svg@w3.org
On 2013-10-30 11:27, Regina Henschel wrote:
> Hi all,
>
> while implementing an SVG import for Apache OpenOffice, we come across 
> this problems:
>
> Take this path definitions
> (A) d="m40,20 -20,10 30,10 z l10,-10"
> and
> (B) d="m40,20 -20,10 30,10 z m0 0 l10,-10"
>
> Which vertices exists? How many markers are created and what 
> directions have these markers?
The spec states (section 8.3.3): "If a "closepath" is followed 
immediately by a "moveto", then the "moveto" identifies the start point 
of the next subpath. If a "closepath" is followed immediately by any 
other command, then the next subpath starts at the same initial point as 
the current subpath." So from that point of view both of these paths 
consist of two subpaths with 3 and 1 segments, respectively, with the 
same vertices.

Now, the spec says (section 11.6.3) that marker-start "defines the 
arrowhead or polymarker that shall be drawn at the first vertex of the 
given ‘path’ element or basic shape". A little further in that same 
paragraph it seems to be implied that "first" and "last" should be 
considered to apply to subpaths (rather than the entire path), and that 
in the event of a closed subpath the first and last vertex should be 
considered the same (and that one might thus have to draw two markers at 
the same position, depending on the values of marker-start and 
marker-mid). It would thus seem that for both paths you should have the 
following sequence of markers: start mid mid end start end.

Markers are a little tricky though. When it comes to the orientation the 
spec seems to imply (section 11.6.2, explanation of the orient 
attribute) that if a closepath is followed by an explicit moveto, the 
orientation of the end marker corresponding to the closepath should be 
the same as the orientation for the starting point of the subpath closed 
by the closepath, and that the orientation can be found by considering 
the last and first segments of that subpath (the one that is closed by 
the closepath), or alternatively that this just holds for the start 
marker, and that the end marker just acts like that path ends completely 
at that point (but that seems weird). However, when a closepath is /not/ 
followed by a moveto, you should take the the last segment of the 
subpath closed by the closepath (so the line segment drawn by the 
closepath) and the first segment of the /subsequent/ path. (Confusingly, 
in the latter case the orientation of the marker corresponding to the 
start of the second subpath does not appear to be altered...)

In summary: (as far as I can tell) both paths have the exact same 
vertices and /types/ of markers, the orientations do differ though. In 
the first case the orientation of the marker corresponding to the 
closepath will be determined by the line segment corresponding to the 
close path (from [30,10] to [40,20]) and the final line segment (from 
[40,20] to [10,-10]), the orientation of the marker corresponding to the 
first point of the second subpath would be solely determined by the 
final line segment (from [40,20] to [10,-10]). In the second case the 
two subpaths are essentially handled separately.
> Is stroke-linejoin or stroke-linecap used in point (40|20)?
> For example B
> stroke-linejoin between lines (40|20)(20|30) and (50|40)(40|20)
> and on top of it
> stroke-linecap from line (40|20)(50|10)
Not sure about linecaps/-joins, but I hope the above will at least 
provide a bit more insight. I would follow the references given above 
and have a careful look yourself, there are quite a few corner cases and 
exceptions. (Be sure to also have a look at the 'path' element 
implementation notes: section F.5.)
Received on Thursday, 31 October 2013 20:45:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:46 UTC