- From: Erik Dahlstrom <ed@opera.com>
- Date: Fri, 21 May 2010 10:45:19 +0200
- To: "Alex Danilo" <alex@abbra.com>
- Cc: public-svg-wg@w3.org
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]. >> 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. Cheers /Erik [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:45:59 UTC