Re: paths-data-20-f.svg

On Fri, 21 May 2010 14:29:15 +0200, Chris Lilley <> wrote:

> On Friday, May 21, 2010, 2:25:09 PM, Chris wrote:
> CL> I also don't see any errata that relate to this test. As its at
> CL> the end of the table of errata tests, that means it was added
> CL> later on. I don't find a mention in minutes about that though.
> Of course I find relevant minutes right after sending that mail
> ED: I think the grammar for the elliptical has been fixed
> <ed> paths-data-20-f.svg
> ED: I added a test for it
> ... would like some one to view the test
> DS: Jeff Schiller had more to say about the syntax on the mailing list
> ED: My update was after his email
> ... it covers white space after the first and second flags
> DS: We could mention at least in the context of SVG 2.0
> ... a lacuna value for any given coordinate that is out of range
> ... can say it is assumed to be zero
> ED: I'm not sure really
> ... if you want to go with 1 or 0 then you have a bias
> DS: It's only cases where the arc flags are messed up
> ... what do you do with it?
> ED: We just check if its 1 or 0 that's all
> ... if it's say 2
> ... we just say it's invalid
> ... you can't really parse it as anything else
> Looks like that discussion took place without noticing that, as Alex  
> points out, there has been language in the spec since SVG 1.0 saying  
> what to do with such a value.

It's a good find, but do note that the path grammar is just the same in  
SVG 1.0, see, and couple  
that with  
(first bulletpoint). A conforming SVG user agent would not render the  
invalid arc segment (invalid in the 'd' attribute is defined by the path  
attribute grammar), or in other words: I think the test is valid.

I think the arc implementation notes are on a higher level than the path  
grammar, and that they can be applied later (or in other cases, e.g  
rounded rects where the corners are defined as arc segments). And it is  
good that it describes what happens when values are out-of-range, or  
invalid since an implementation might internally get into such states.

I don't really care that much if any single digit is allowed in the 'flag'  
production in the path grammar, but having more than one digit (or signs)  
allowed would complicate things for no good reason. And IIRC we had a  
majority of implementations already behaving the same (that is, treating  
the arc segment as invalid if the 'flag' part was anything else than '1'  
or '0').


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog:

Received on Friday, 21 May 2010 13:07:42 UTC