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