Re: [Lib2geom-devel] Dropping invalid arc segments in parser

[Johan E. <jbc...@sw...>]

On 5-8-2014 21:15, Tavmjong Bah wrote:
> On Tue, 2014-08-05 at 20:46 +0200, Johan Engelen wrote:
>> Hi all,
>>    Liam just committed a bug fix to Inkscape trunk, regarding our SVG
>> parser.
>>
>> SVG spec says:
>> "If the endpoints (x1, y1) and (x2, y2) are identical, then this is
>> equivalent to omitting the elliptical arc segment entirely." [1]
>>
>> Liam changed the parser so that it will simply drop such segments:
>>
>>      void _arcTo(double rx, double ry, double angle,
>>                  bool large_arc, bool sweep, Point p)
>>      {
>> +        if (_current == p) {  // sic, probably should be
>> are_near(_current, p)
>>
>> +            return;
>> +        }
>>          _quad_tangent = _cubic_tangent = _current = p;
>>          _sink.arcTo(rx, ry, angle, large_arc, sweep, p);
>>      }
>
>> I am not sure about this change. We are not dropping any degenerate
>> bezier segments in our parser.
> I think this is not the same as a degenerate bezier. This describes an
> ellipse with given major and minor axis but there is no way to figure
> out where along the ellipse one should start drawing. The following path
> consists of four very different (almost complete) ellipses where the
> final points are just a little bit different from the starting points:
>
>      <path d="m 50,50
> 	     a 20 30 45 1 0 1,1
> 	       20 30 45 1 0 -1,-1
> 	       20 30 45 1 0 -1,1
> 	       20 30 45 1 0 1,-1"
> 	  style="fill:none;stroke:black"/>

Ok, I see you're saying that "a 20 30 45 1 0 0,0" is ambiguous, hence 
invalid and the parser can skip it. (degenerate line segments are not 
ambiguous)
This would vote in favor of floating point comparison, but I think in 
the interest of (human) predictability, the equals-check should be made 
are_near. Do you agree?

regards,
   Johan