Changing path ID breaks text 'Put on Path' reference

In your attached example it looks like the circle used for 'Put on Path' no longer exists or the 'ID' of the circle has been (manually or scripted) changed after applying 'Put on Path', thus breaking the reference (the text is like an 'Orphaned clone'). Did you apply an extension that renames all paths by applying a 'Starbust' kind of effect?

Does it really happen if you just follow your steps 1-6?

I manually changed the IDs; sorry. I had no idea that would break the references. It didn't even occur to me to put that in the steps because I thought it was inconsequential.

If this is the case I would request an enhancement to see the effect of changing the IDs live, possibly with a warning message indicating that it is about to happen, so it's immediately apparent what's happened rather than being a surprise upon re-opening a file.

Also, where is the reference data located in the XML? I don't see it anywhere.

> I manually changed the IDs; sorry. I had no idea
> that would break the references.

Use the "Label" field in the object properties dialog to add a custom tag to the object. IDs have to be unique, therefore it is better not not manually edit them and keep them as assigned by Inkscape.

> If this is the case I would request an enhancement to see
> the effect of changing the IDs live

Could you file a separate feature request for this?

> where is the reference data located in the XML?

It is stored with the linked object i.e. the text object:
 <textPath xlink:href="#path3159" …>

see also: <http://www.w3.org/TR/SVG11/text.html#TextOnAPath>

Where should I file feature requests?

Apart from that you may close this.

Thank you for your time.

Feature requests are handled in the bug tracker too: just file a report describing the the problem in more general terms (changing ID breaks object references not only for text-put-on-path: clones and connectors for example are also affected, as well as text-flowed-into-frame) and someone from the bug team will set the bug importance to 'Wishlist'.

Possibly related:
Bug #168714 in Inkscape: “Connection lost when object label changes”:
<https://bugs.launchpad.net/inkscape/+bug/168714>
(I just updated that report and requested feedback because either the problem as reported has been fixed since 0.45, or it is about the same issue as you stumbled over with text-put-on-path: changing the object ID manually breaks object references)

On second thought it was premature to close this report as 'Invalid'. From the user's perspective there is no indication that the link to the path is lost after changing the object ID of the path.

There are two things that could be improved:
1) ID changes have to be updated automatically in the referencing objects (xlink:href): this report
2) visually update the document after changing the ID (might be costly in terms of performance?): new feature request

Thank you.

#1 would be very useful for what I was trying to, although, it would not necessarily be for someone who is manually changing references on purpose. So I still think that issuing a warning dialog would be more appropriate, as I described in my feature request: https://bugs.launchpad.net/inkscape/+bug/591639.

As for #2, when I went in and changed the `xlink:href`s manually to reflect the new IDs, the document DID update live, and very quickly, i.e. it didn't seem to tax my system (which isn't very fast) so I don't think performance would suffer; it's just a matter of having it happen when a change de-references an object, not just when it (re-)references one.

> As for #2, when I went in and changed the `xlink:href`s manually to
> reflect the new IDs, the document DID update live, and very quickly,
> i.e. it didn't seem to tax my system (which isn't very fast) so I don't
> think performance would suffer; it's just a matter of having it happen
> when a change de-references an object, not just when it (re-)references
> one.

Changing the link in the xlink:href of the referencing object seems "easier", but when editing an arbitrary ID you have to search the whole document to find out if it is used in the xlink:href attribute of another object: the reference is one-directional and the link target doesn't know per se about being linked to.

OTOH maybe the way 'delete'ing a referenced object reverts (most or some types of) referencing objects to regular objects could also be triggered when updating the object ID: text-put-on-path is undone and the text switches back to its prior position, giving immediate feedback to the user.