Re: PathSeg interface

A parser with an escaping mechanism could be very useful.
I have done the implementation for a path extension (see
https://github.com/moissinac/SuperPath) and I can't use the  parser
integrated in the browser. I've my own ugly parser mainly inspired by the
one from canvg
I know that some other developers have other extensions so it could be
useful to get the result of the parsing but also to be able to plug a
handle when the conformant parser find a non-standard path data.
Clearly, having access to the parser results is useful. in a lot of
scenarios: maping, gaming, ...

--
Jean-Claude Moissinac <http://moissinac.wp.mines-telecom.fr/>

2015-02-12 11:14 GMT+01:00 Paul LeBeau <paul.lebeau@gmail.com>:

>
> > RESOLUTION: Drop the SVGPathSeg* interfaces if Erik verifies
>    the use counter values are correct
>
>
> I'm surprised it is zero - even though the API interface is a bit unwieldy
> and has only very basic support from the browsers.
>
> For instance FF and Chrome support pathSegList and animatedPathSegList,
> but IE only supports pathSegList and none of them support the
> normalisedPathSegList variants.  Which is a pity, because there are a lot
> of cool tricks that could be done with a flattened path.
>
>
> Even if it is extremely rarely used, surely it would be a huge shame to
> remove the only easy way to get access to the list of path segments?  Do we
> really expect users to write their own d attribute parsers?
>
> Paul
>
>
>
>
>