Expanded alternative to normalized matrix file encoding
I like to use inkscape to build UI elements which I can access in raster form via a caching renderer. Typically, there are one or two aspects within the xml which I need to vary in order to get the dynamic effect I am looking for. I'll substitute values into the xml and render according to the request. Unfortunately, with the normalized matrix form being the final encoding, access to all of the basic transformations is cryptic. I would really like to be able to assign an id to an element, and access its discrete transforms individually, by type. For example, I would like to be able to render a watch into raster form by specifying a normalized rotation for hour, minute, and second.
It would be pretty easy for me to do this now, only if I had the option of not collapsing the xml for transforms, and instead could access individual named or numbered transformations which constitute them, in addition to being able to access their high-level parameters, like "rotate by" instead of in affine form. Think of it as leaving procedural hooks for specialized renderings. Perhaps a property on a transform which indicates it should remain separate would suffice.
Reactions?
On 10/11/06, Jonathan Shook <jshook@...400...> wrote:
It would be pretty easy for me to do this now, only if I had the option of not collapsing the xml for transforms, and instead could access individual named or numbered transformations which constitute them, in addition to being able to access their high-level parameters, like "rotate by" instead of in affine form.
I.e. you want Inkscape to write "rotate() translate()" etc instead of just "matrix()"?
Well, at least Inkscape can _read_ transforms in any format. So if you use scripts for generating SVG and Inkscape only for rendering, it should work. Or am I missing something?
In other words, my question is: why do you need to _read_ transforms written by Inkscape? For example, if you want to move an object by a given distance, and if this object has matrix() written by Inkscape, you can simply add your own move on top of that, i.e. "matrix() translate()" and it should work.
On 10/11/06, bulia byak <buliabyak@...400...> wrote:
On 10/11/06, Jonathan Shook <jshook@...400...> wrote:
It would be pretty easy for me to do this now, only if I had the option of not collapsing the xml for transforms, and instead could access individual named or numbered transformations which constitute them, in addition to being able to access their high-level parameters, like "rotate by" instead of in affine form.
I.e. you want Inkscape to write "rotate() translate()" etc instead of just "matrix()"?
Well, at least Inkscape can _read_ transforms in any format. So if you use scripts for generating SVG and Inkscape only for rendering, it should work. Or am I missing something?
In other words, my question is: why do you need to _read_ transforms written by Inkscape? For example, if you want to move an object by a given distance, and if this object has matrix() written by Inkscape, you can simply add your own move on top of that, i.e. "matrix() translate()" and it should work.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
I would actually like to author in Inkscape, and render with it, but allow for an intermediate step of transforming specific elements in specific ways with a mostly-ignorant script. If there were a way to call parameterized scripts during the headless rendering mode, It would address this need and then some, I think.
participants (2)
-
bulia byak -
Jonathan Shook