W3C home > Mailing lists > Public > www-svg@w3.org > February 2015

Re: PathSeg interface

From: Jean-Claude Moissinac <moissinac@enst.fr>
Date: Thu, 12 Feb 2015 11:29:06 +0100
Message-ID: <CAP8HVi1tF4RfkLwp=YnOhc8ZyNFbYTZkcHHFn=8b-VHbps3zYg@mail.gmail.com>
To: Paul LeBeau <paul.lebeau@gmail.com>
Cc: www-svg <www-svg@w3.org>
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
Received on Thursday, 12 February 2015 10:29:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:58 UTC