Incorrect handling of <text> without <tspan>
I have been working on a patch for bug: https://bugs.launchpad.net/inkscape/+bug/167904
sp_te_insert_line
I basically created a working patch (excluding end of string line breaks and probably spacing issues). The patch checks if the text in contained in a text box is a child of svg:text instead of svg:tspan . If this is true a <tspan> is inserted as a child of the <text> and the string is transfered to become a child of the <tspan> . this This works but it fails for strange reasons. If the text box is selected and the cursor is moved over with the keyboard and a line break is inserted, inkscape crashes. I traced this back to a problem occurring with the Glib::ustring::iterator s being used. In the instances that the patch fails the iterator's values don't match up to their expected value. The problem also occurs after a line break, an undo, and a repeat of the line break.
I'm fairly new to the code base so I may be doing things out of order or failing to call a necessary function. I'm not exactly sure why this is occurring after these actions are performed. What can I do to solve this issue. I have posted the code in question to the bug report. I have a feeling this problem is occurring from the layout obtained from the SPItem and the actions that occur afterwards. Thanks
I have been working on a patch for bug: https://bugs.launchpad.net/inkscape/+bug/167904
Thanks.
I basically created a working patch (excluding end of string line breaks and probably spacing issues). The patch checks if the text in contained in a text box is a child of svg:text instead of svg:tspan . If this is true a <tspan> is inserted as a child of the <text> and the string is transfered to become a child of the <tspan>.
That seems like a sensible approach.
This works but it fails for strange reasons. If the text box is selected and the cursor is moved over with the keyboard and a line break is inserted, inkscape crashes. I traced this back to a problem occurring with the Glib::ustring::iterator s being used. In the instances that the patch fails the iterator's values don't match up to their expected value. The problem also occurs after a line break, an undo, and a repeat of the line break.
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 have posted the code in question to the bug report.
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 Saturday, May 9, 2009, 4:17:02 AM, Jimmy wrote:
J> I basically created a working patch (excluding end of string line breaks J> and probably spacing issues). The patch checks if the text in contained J> in a text box is a child of svg:text instead of svg:tspan . If this J> is true a <tspan> is inserted as a child of the <text> and the string is J> transfered to become a child of the <tspan>
While this will work, its not clear to me why Inkscape always requires text nodes to be a child of a tspan element rather than also allowing them to be directly as a child of a text element.
Are mixed content models a problem?
Note that any scripts which manipulate text are likely to be broken by moving content into a child element.
On 5/9/2009 1:11 PM, Chris Lilley wrote:
On Saturday, May 9, 2009, 4:17:02 AM, Jimmy wrote:
J> I basically created a working patch (excluding end of string line breaks J> and probably spacing issues). The patch checks if the text in contained J> in a text box is a child ofsvg:text instead ofsvg:tspan . If this J> is true a<tspan> is inserted as a child of the<text> and the string is J> transfered to become a child of the<tspan>
While this will work, its not clear to me why Inkscape always requires text nodes to be a child of a tspan element rather than also allowing them to be directly as a child of a text element.
Are mixed content models a problem?
Note that any scripts which manipulate text are likely to be broken by moving content into a child element.
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)
participants (4)
-
Bob Jamison -
Chris Lilley -
Jimmy -
Richard Hughes