- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 23 Jun 2011 19:58:16 -0700
- To: Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Cynthia Shelly <cyns@microsoft.com>, david.bolter@gmail.com, Mike@w3.org, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On 6/23/2011 7:50 PM, Cameron McCormack wrote: > Charles Pritchard: >> That stated: Does anybody here object to the stringification methods >> I've put forward? > I think being able to get and set the current path as a string using SVG > path syntax is a fine idea, pretty useful. As I mentioned I don’t > really see the need to wrap the string in an otherwise opaque object. I only separated it from the opaque object to separate the two proposals; one being a Path object, the other being a set of stringify methods for transformations and paths. >> They in no way "step on" the propriety of SVG -- they in fact enhance >> interoperability, > (Not sure how they enhance interoperability if nobody implements them > yet…) Some vendors do implement normalized strings. This enhances interop, even without normalized strings, as it allows the scripting environment to create normalized strings and then use them, both with canvas, and with SVG paths. I've personally implemented SVG, and I've worked with other developer's implementations of SVG which worked atop canvas. I've also worked with issues where method calls had unfortunate overhead. In all cases, it's a big help to have the Canvas implementation recognize normalized SVG strings. And it's relatively inexpensive to add to Canvas implementations. >> Cameron: I did see a minor aside from you about the arcTo command -- >> I'd like to remind you that SVG normalized strings took this into >> account and it was decided that arcTo precision was not necessary; the >> curves handled by SVG normalization were deemed sufficient. If they >> are/were not sufficient, then arc would have to be included in the >> normalization spec.... > I think the whole point of SVG exposing path data as either normalised > or un-normalised is that user script may find it easier not to have to > deal with both relative and absolute commands, arcs, etc. And the implementation. It's a lot of extra work, and it's not really necessary, as it can be handled at other points in the pipeline. >> it has not been, I've not seen any technical reason why this decision >> should be changed. >> author cannot always get back a path identical to one they built up >> using the moveTo/lineTo/arcTo/etc. commands. That's correct; they do not need identical information either. There's nothing in the spec requiring such precision, nor is there anything in the target environments. -Charles
Received on Friday, 24 June 2011 02:58:54 UTC