Thanks. That seems like a sensible approach. To make manipulations of the original text possible, Layout objects maintain pointers back to the objects from which they were generated. These pointers are becoming invalidated by the first set of changes that you are doing, so when the rest of the code goes and tries to insert the line break it accesses stuff that it thinks ought to be where it left it but isn't. All the other functions get round this problem by dividing their process into two distinct parts (although this may not be evident from reading the code): they plan what they are going to do and read all the necessary data, then they execute that plan without touching the Layout object. You could also work around it by forcing a re-layout of the text between the two phases of the transform and calling Layout::validateIterator(), but a re-layout is time-consuming. I'm not exactly clear on where this snippet is supposed to go. Can you please use unified diffs in the future. With regard to the space at end problem, that'll be because the <text> element lacks an xml:space="preserve" attribute. This is a continuing problem with imported text objects because Inkscape is behaving entirely according to the SVG spec, it's just extremely baffling to the user when their characters don't appear. R.

On 5/9/2009 1:11 PM, Chris Lilley wrote: I have a small question about the SVG-DOM api. Why is it, that for every DOM list, (NodeList for example) , there is a readonly "length" property, and an "item(index)" accessor method, but in contrast in SVG, the property is "numberOfItems", and the accessor is getItem(index) ? bob (ishmal)