Re: [svgwg] SVG2 path data coordinates are currently spec'd as integers.

I definitely agree on the basic tests.  There was one goof reported against a parser - as a security/spoofing problem(!) - where an example 10000 char path string was submitted with no explanation.  One was supposed to just *eyeball* the glitch present somewhere in the string.  Depending on the font the problem might not leap out at you.
> ......  M 133.00,127.0O C 133.00,127.00 149.53,127.00 149.53,127.00  ......

As a treat the reporter had the following path commands display something quite rude. :smile:
       
The report was suggesting that silently truncating SVG path strings at the first error could allow nefarious data to be introduced unnoticed.  That parser *was* following the rules in [9.5.1. Error handling in path data](https://svgwg.org/svg2-draft/paths.html#PathDataErrorHandling).  Whether that program being *too coy* about a detected error was wrong I couldn't say.

Implicit in the rules is how something like `12.34.56` should be handled.  It should come out as `12.34` then `.56`.  So your example of `M0.0.0.` should fail but `M0.0.0` would pass.  Just playing with my own number format tests I had 60+ tests.  Translating all those into visual form ala the W3C tests would be difficult.  Making parsing failures spell rude words would be extra credit.

(Still working on notes - while the interest here was in moving from ABNF to EBNF syntax "because CSS" (I thought), it is interesting that the former CSS specs never used a 'BNF' form, but only ref'd Yacc and Flex syntaxes, and now CSS 2.2 uses only prose and [railroad diagrams](https://www.w3.org/TR/css-syntax-3/#token-diagrams).  Maybe the future is "steam punk SVG grammar"?)

-- 
GitHub Notification of comment by tshinnic
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/335#issuecomment-320349171 using your GitHub account

Received on Friday, 4 August 2017 20:45:11 UTC