search

bodoni / svg

Composer and parser for SVG
Other
302 stars 44 forks source link

Numbers in paths do not support scientific notation. #3

Closed nical closed 8 years ago

nical commented 8 years ago

This issue was found when trying to parse the logo of the lyon crate: https://github.com/nical/lyon/blob/master/assets/lyon-logo.svg.

The parser for paths uses Reader::consume_number which is modeled after https://www.w3.org/TR/SVG/types.html#DataTypeNumber.

This part of the spec does not mention scientific notation (like "2e-4"), most likely because of restrictions to the style sheet grammar.

However, scientific notation is explicitly supported by the path specification (see the grammar in https://www.w3.org/TR/SVG/paths.html#DAttribute).

Unfortunately SVG files generated by Inkscape (and probably many other vector graphics programs) are full of paths with numbers in scientific notation so it would be very useful for this library to support them at least in paths.

nical commented 8 years ago

There's a number parser in https://github.com/rust-lang-nursery/rustc-serialize/blob/master/src/json.rs#L1473 which I think is a solid implementation. Obviously it cannot be used as-is but it could be useful as a reference.

IvanUkhov commented 8 years ago

Thanks for the issue! Yes, scientific notation is in the grammar of path data, and it’s also in the grammar of basic data types you mentioned. The reason it’s not in consume_number is that, since I didn’t really need it, I decided to postpone it until later. It seems this later has come.

nical commented 8 years ago

Fun story, the latest draft for SVG 2 lost the scientific notation in the path spec. I am pretty sure it wasn't intentional so I filed https://github.com/w3c/svgwg/issues/286.

IvanUkhov commented 8 years ago

Hmm, that’s interesting. Let’s then wait and see what they have to say about that.

nical commented 8 years ago

SVG 2 contains some major breaking changes from SVG 1.x. If you want to support SVG 2 specifically, I suggest creating a separate parser or adding a setting to the existing parser. All of the existing tooling is based on SVG 1.x, and it will be years before SVG 2 is finalized and some even small portion of the existing software moves to SVG 2.

I think that in order to be useful, this crate needs to at least be compatible with the 1.1 specification.

IvanUkhov commented 8 years ago

Yes, I absolutely agree.