Comment 17 for bug 412928

What about a similar approach to what inkscape is already doing with text -> path, where it keeps a copy of the text object so the path can then be converted back to a text object, edited, and back to a path? For inverse clipping, all you would do is, not even needing the encompassing rectangle, but just some path form of the object (I tried with a linked offset -- clones don't work, since they are not paths) being internally created to perform the path->difference, and then using that new path as the clipping object, but it remains internally linked to the original object, such that the original object can be edited, and when this happens, the clipping path is automatically updated. So the functionality to the user would be identical to clipping, but now they can do an inverse clip, while still having an SVG spec compliant doc.