Another confusing concept. SVG allows to store transformations (moves, rotates, etc) both "natively" (in the object's own coordinates) and as a transform= attribute that is applied "after the fact". Of the many commands that move/rotate objects, some (most) write the new coordinates directly into the object, but some just add a transform= attribute without changing anything else in the object. I see no apparent logic behind this difference in behavior.
Now, the "remove transformations" command simply erases the transform= attribute if it is present. Recent Sodipodi adds "apply transformations" which writes the transform= into the object and then removes it (i.e. no visible change). I think this mess is very confusing and serves no useful purpose. To an artist, "remove transformations" works as a weird sort of undo whose results are generally unpredictable, and "apply transformations" does nothing at all. So I propose:
- remove the "remove transformations" command.
- fix the remaining commands that add transform= so that they always "apply" their transformations to the objects at once. (In particular, scaling a text object must affect its font size; transforming a group must write transformations into the group's members instead of adding transform= to the entire group.)
I may have missed something, so please argue.
_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
bulia byak wrote:
Another confusing concept. SVG allows to store transformations (moves, rotates, etc) both "natively" (in the object's own coordinates) and as a transform= attribute that is applied "after the fact". Of the many commands that move/rotate objects, some (most) write the new coordinates directly into the object, but some just add a transform= attribute without changing anything else in the object. I see no apparent logic behind this difference in behavior.
Now, the "remove transformations" command simply erases the transform= attribute if it is present. Recent Sodipodi adds "apply transformations" which writes the transform= into the object and then removes it (i.e. no visible change). I think this mess is very confusing and serves no useful purpose. To an artist, "remove transformations" works as a weird sort of undo whose results are generally unpredictable, and "apply transformations" does nothing at all. So I propose:
remove the "remove transformations" command.
fix the remaining commands that add transform= so that they always
"apply" their transformations to the objects at once. (In particular, scaling a text object must affect its font size; transforming a group must write transformations into the group's members instead of adding transform= to the entire group.)
I may have missed something, so please argue.
I can think of one thing...
Isn't the effect of having the original object + transformations, being to keep a clean "master" copy of the original? Maybe for just plain hand-drawn art, this doesn't need to be preserved.
But if we ever get into the DOM scripting part of the SVG spec, we would likely want to keep the original object + each of its transformations. Like, say an object is rotated by angle theta, then translated to a point x,y. Say we want to to animate it by changing theta, thus rotating it, but leaving the translation alone.
We would want then to allow an XPath reference to the object, and to its rotation transform, in order to change its angle attribute explicitly. (Imagine a fireworks 'pinwheel', which has a rotating wheel, with smaller rotating wheels at the ends of its spokes.)
Scripting and DOM access are 'future' features, but we should make sure we do not disable them now.
Bob
participants (2)
-
Bob Jamison -
bulia byak