W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2010

Re: paths-data-20-f.svg

From: Alex Danilo <alex@abbra.com>
Date: Fri, 21 May 2010 18:52:55 +1000
Message-Id: <70IR2L.0HEW49YT3WO5@abbra.com>
To: "Erik Dahlstrom" <ed@opera.com>
Cc: public-svg-wg@w3.org
Hi Erik,

--Original Message--:
>On Fri, 21 May 2010 05:22:03 +0200, Alex Danilo <alex@abbra.com> wrote:
>> Answering myself:
>> You wrote:
>>> Hi All,
>>> 	I've been looking at paths-data-20-f.svg which is supposed to
>>> test 1.1F2 Errata.
>>> 	I don't see any errata relating to this test, but more
>>> importantly it appears to be inconsistent with the current draft.
>See ACTION-2754 for details[1].

Thanks for the pointer.

>>> 	For example, one of the sub-tests (I haven't looked at
>>> all of them yet) contains:
>>>    <!-- out of range large-arc-flag value -->
>>>    <path d="M280,120 h25 a25,25 0 1,0 -25,25 z" fill="lime"  
>>> stroke="lime"/>
>>>    <path d="M280,120 h25 a25,25 0 6 0 -25,25 z" fill="red"/>
>>> 	In the test matrix, Opera and Firefox have passes against them
>>> while everyone else fails.
>>> 	It appears that the test is expecting rejection of the path with
>>> the 'out of range' large arc flag.
>If the path syntax is invalid (according to spec text / EBNF grammar) then  
>the path implementation notes describes what should happen.
>>> 	However, the original 1.1 spec and the current 1.1F2 draft
>>> both state in the Elliptic Arc implementation notes:
>>> "Any nonzero value for either of the flags fA or fS is taken to mean  
>>> the value 1."
>>> 	So either the test is wrong, or the spec. has not been corrected
>>> to indicate this is meant to be an error condition.
>> The BNF in the main part of the spec mandates the '0' or '1' for the
>> flag.
>> So, the Elliptic Arc implementation notes need to be corrected.
>Hmm, I don't see the harm in keeping that wording since it's independent  
>of how the arc segment was generated.

Well it's superfluous then. It implies that a non-zero value apart from 1
is possible - and that's what older implementations probably handled OK.
So it only serves to confuse authors and implementers.

I'd be inclined to remove it. It doesn't add anything to the spec. if the only possible
value is 0 or 1.


>[1] http://www.w3.org/Graphics/SVG/WG/track/actions/2754
>Erik Dahlstrom, Core Technology Developer, Opera Software
>Co-Chair, W3C SVG Working Group
>Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 21 May 2010 08:53:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:43 UTC