On 6/27/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
Create a new text object with some text in it. Make sure it is visible (i.e. not in the defs). Create a second text object with nothing inside except a use element that refers to the first text object.
I'm not sure this is meaningful. A <use> is defined as something which is replaced by the "shadow copy" of the subtree it references. In this case, placing <use> that refers to <text> inside another <text> is equivalent to creating nested <text> element. But from my reading of SVG spec, this is not allowed. Only tspan, tref, textPath, altGlyph are included in %SVG.TextContent.class; as you can see at http://www.w3.org/TR/SVG11/text.html#id5191993. So, for example, Batik does not display the text with such <use> at all.
So, while Inkscape's behavior is weird in this case, it's not something that has any real world significance. We don't claim to correctly render invalid files :)
As for the jumping, it is I think caused by the fact that the <text> containing the <use> has its own x/y attributes, and Inkscape gets confused as to which x/y to use for the cloned nested text. In any case, this is quite different from a tref because tref copies over only character data, not any x/y or transforms, from the source it refers to. In fact, tref is very similar to tspan which we support more or less correctly, except that in tref the character data comes from a different place - so perhaps you should base your tref code on tspan because they are quite similar.
bulia byak wrote:
So, while Inkscape's behavior is weird in this case, it's not something that has any real world significance. We don't claim to correctly render invalid files :)
This is fair :)
In fact, tref is very similar to tspan which we support more or less correctly, except that in tref the character data comes from a different place - so perhaps you should base your tref code on tspan because they are quite similar.
That's exactly what I've been trying to do. I want the tref to pretty much be a tspan and have modeled most of the new code after it; I took only what was absolutely necessary from the use code (i.e. the actual referencing stuff). At first, I didn't think it would be necessary to have the node being referenced as a child in the same way as the use element does it, but I couldn't see how else to have it automatically use the text content of the object it referred to. However, this does lead to the same situation you described above. Namely, the nested text thing.
However, it's starting to sound to me like the only valid option is to literally copy the text over and update it when the original changes. I had been avoiding that because duplication is evil, but there are several issues surrounding doing is any other way. Without getting into those issues right off hand, what is your opinion of this approach? Is that what you pictured all along?
Gail
On 6/27/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
However, it's starting to sound to me like the only valid option is to literally copy the text over and update it when the original changes. I had been avoiding that because duplication is evil, but there are several issues surrounding doing is any other way. Without getting into those issues right off hand, what is your opinion of this approach? Is that what you pictured all along?
Well, at _some_ level you have to duplicate it - the only question is what is the best level to do that :) I think it makes perfect sense to do the copying at the level which is smart enough to re-copy when it senses the source change.
bulia byak wrote:
Well, at _some_ level you have to duplicate it
This is reassuring :) I was trying very hard to just point to the objects with text, thinking I could strip it out by walking the hierarchy in a somewhat automatic fashion. However, to literally copy the strings over is much easier and avoids the issues of accidentally using the style information from the objects referred to, or, alternatively, having special cases for tref sprinkled all over the text code.
(And yes, it's unfortunate that I've come full circle after all this time - but think of all that I've learned in between... :)
Thanks, Gail
participants (2)
-
bulia byak -
Gail Banaszkiewicz