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. > 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…) > 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. > it has not been, I've not seen any technical reason why this decision > should be changed. I think for your use case, which deson’t involve author script manipulating the path data returned from getCurrentPath, I don’t see the need to have to normalise the path data before returning it. All that I was pointing out with the arcTo comment was that if you require the path to be normalised before being returned to getCurrentPath, the script author cannot always get back a path identical to one they built up using the moveTo/lineTo/arcTo/etc. commands. -- Cameron McCormack ≝ http://mcc.id.au/Received on Friday, 24 June 2011 02:51:14 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:30 UTC