Re: Number of vertices unclear, when using closepath command

On 2013-11-02 21:06, Regina Henschel wrote:
> Hi Jasper, hi all,
>
> Jasper van de Gronde schrieb:
>> 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.
>
> It is clear, that there are three line segments for the first subpath 
> and one line segment for the second subpath. But see it from the view 
> of a point. All agree, that the point (20|30) has one incoming line 
> segment and one outgoing line segment. But the point (40|20)?
That might be a slightly misleading way to look at it. SVG doesn't 
really deal in "points" as such. Rather, you have line (/curve) 
segments. Possibly that is why markers get a bit complicated. If one 
ignores markers for a moment (as they basically just have their own set 
of rules), then in either case the first and last point of the first 
subpath is the same ([40,20]), and toplogically the first and last 
segment of the subpath are connected so that they form a closed loop. 
The second subpath just happens to start at the same point. As far as I 
can tell the spec. does not really allow for any other view. (For 
example, I don't think you would get a "join" between the last segment 
of the first subpath and the first segment of the second subpath.)
>> 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...)
>
> It seems to be not clear. For example, test the files contained in the 
> .zip file in https://issues.apache.org/ooo/attachment.cgi?id=81841
>
> Internet Explorer has marker-start and two marker-mid on point (40|20) 
> in case B, but only marker-start and one marker-mid in case A. It 
> might paint the marker of the second subpath identical to the end of 
> the first subpath, on top of each other; not able to rule it out only 
> from view.
This appears to match the spec and the description I gave above. Except 
that although it would seem to make sense in case A to just draw one 
marker mid for the endpoint of the first subpath and the first point of 
the second subpath, I do not think the spec really supports this view.
> Seamonkey too has 1+2 markers in case B and 1+1 markers in case A. But 
> it draws the marker-start different from Internet Explorer.
Assuming it does the same as Firefox (align the marker-start as if the 
path was not closed), this seems to go against the spec. The spec is 
pretty explicit about the orientation of marker-start in the face of 
closed subpaths (it actually goes through the trouble of saying "In *all 
*cases for closed subpaths ...", emphasis added).
> Inkscape shows 1+2 markers in both cases with identical orientations, 
> which I think is wrong because of the explicit rule in section 11.6.2.
Inkscape's rendering of markers is (unfortunately) fairly broken. In 
fact, even without the fact that we appear not to take closed paths into 
account, we would probably have some issues with differentiating between 
case A and B.
> Chrome has 1+2 markers in both cases, but orientations are different 
> from the other implementations. That both cases are identical, seem 
> wrong to me, same as for Inkscape.
To be honest, I have no idea what Chrome is doing to get these 
orientations, but I agree that it does not seem to match the spec.
>> 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.)
> If reading the spec gave an unambiguous solution, there would not be 
> so many different implementations.
You might think so, but as demonstrated above, that does not appear to 
be the case (at least for markers, I have not looked at line joins yet, 
as I'm less familiar with that part of the spec). It is just a horribly 
complicated and unintuitive part of the spec (with all due respect to 
those who wrote it, as this stuff is simply quite difficult to do well, 
and there were probably all sorts of conflicting requirements and so 
on). Also, this part of the spec does get exercised less than some of 
the other parts, which means that bugs take longer to get noticed. And 
this is all sort of self-reinforcing (because the implementations differ 
it gets used less and it takes longer to fix things, so it gets used 
less, priorities become lower, etc., etc.), leading to the marker mess 
we have today. So thank you for taking the time to get to the bottom of 
this.