RE: Bug in grammar for paths

Hi Amelia, all,

 

Yeah, the output from Illustrator, for example, tends to be gnarly and not easily parsed by JavaScript. It would have been nice if the syntax had been a bit easier, since a static collection of paths is not always the end result, nor the most accessible (for search engines, screen readers, and communities downstream).

 

Cheers

D

 

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: Saturday, April 29, 2017 3:15 PM
To: Jirka Kosek
Cc: Paul LeBeau; www-svg
Subject: Re: Bug in grammar for paths

 

These quirks of the path grammar are used by SVG minimizers/optimizers, so they can't be changed now.  Content relies on the fact that 4-3.1.3e2.4 is four separate numbers (equivalent to 4, -3.1, 0.3e2, 0.4).

 

Yes, it does require a more complex parser.  You can't just split the string on separators, you need to scan through it character by character, matching the sequence as defined, using a greedy algorithm.  A number is as many characters as make sense in a number, in order, and no more.

 

Jirka Kosek wrote:

Seems that grammar is only illustrational because there are other issues
with it -- for example grammar accepts only integers not decimal numbers.

 

This was an error from when SVG 2 was edited to add the Bearing command and convert from BNF to EBNF.  There is an open issue, I didn't realize that it never got fixed:  https://github.com/w3c/svgwg/issues/286

 

The SVG 1.1 definition of a "number" is correct (https://www.w3.org/TR/SVG11/paths.html#PathDataBNF). Decimals and scientific notation are allowed.

 

If anyone wants to make a pull request on SVG 2 to fix it, that would be appreciated. We can at least change it in the Editor's Draft, although I don't know when the TR spec will be re-published.

 

~ABR