I would like to be able to select nodes using XPath: https://bugs.launchpad.net/inkscape/+bug/798640
I naively assumed this would be trivial but when I dig in the code it doesn't seem like it is. In particular it is not immediately obvious how to convert between Inkscapes DOM model and libxml2:she model.
The simplest way I can think about now is a workaround involving loading the file with libxml2, and find the nodes in that tree instead.
I can't be the only one wanting to do things like this. I'm obviously missing something, right?
2011/6/18 <joakim@...1974...>:
I naively assumed this would be trivial but when I dig in the code it doesn't seem like it is. In particular it is not immediately obvious how to convert between Inkscapes DOM model and libxml2:she model.
libxml2 is actually only used when loading the document, and we construct a different XML tree based on the one we get from libxml2. The relevant bit is in src/xml/repr-io.cpp:402. As far as I understand this is because our XML tree has support for change notifications and is garbage collected.
The simplest way I can think about now is a workaround involving loading the file with libxml2, and find the nodes in that tree instead.
Yes, you'll have to do this, unless you want to put a lot of effort into rewriting code in src/xml/.
Regards, Krzysztof
On 2011-06-18 10:31, joakim@...1974... wrote:
I would like to be able to select nodes using XPath: https://bugs.launchpad.net/inkscape/+bug/798640
I naively assumed this would be trivial but when I dig in the code it doesn't seem like it is. In particular it is not immediately obvious how to convert between Inkscapes DOM model and libxml2:she model.
The simplest way I can think about now is a workaround involving loading the file with libxml2, and find the nodes in that tree instead.
I can't be the only one wanting to do things like this. I'm obviously missing something, right?
Actually I don't think you are missing something. As far as I know Inkscape has no xpath-like functionality (frankly it's not needed that often). It would be extremely cool to have though, also in the find dialog! You shouldn't need to load the SVG separately though, Inkscape's internal representation more or less mirrors the XML. Besides, I don't think you'd really want to operate on the XML representation, as then you get weird things like having to check for a fill in two places (either as part of the style or as a stand-alone attribute).
BTW, I'm assuming that you would be writing your own XPath processing code (perhaps not necessarily the parser, but at least the part that finds the required nodes). If you meant to reuse an existing library you can probably forget about it (unless it's set up in an extremely flexible manner).
Jasper van de Gronde <th.v.d.gronde@...528...> writes:
On 2011-06-18 10:31, joakim@...1974... wrote:
I would like to be able to select nodes using XPath: https://bugs.launchpad.net/inkscape/+bug/798640%3E I naively assumed this would be trivial but when I dig in the code it doesn't seem like it is. In particular it is not immediately obvious how to convert between Inkscapes DOM model and libxml2:she model.
The simplest way I can think about now is a workaround involving loading the file with libxml2, and find the nodes in that tree instead.
I can't be the only one wanting to do things like this. I'm obviously missing something, right?
Actually I don't think you are missing something. As far as I know Inkscape has no xpath-like functionality (frankly it's not needed that often). It would be extremely cool to have though, also in the find dialog! You shouldn't need to load the SVG separately though, Inkscape's internal representation more or less mirrors the XML. Besides, I don't think you'd really want to operate on the XML representation, as then you get weird things like having to check for a fill in two places (either as part of the style or as a stand-alone attribute).
I don't get this part?
BTW, I'm assuming that you would be writing your own XPath processing code (perhaps not necessarily the parser, but at least the part that finds the required nodes). If you meant to reuse an existing library you can probably forget about it (unless it's set up in an extremely flexible manner).
Well, I was thinking of using the xpath implementation in libxml2 since that is linked already. And I was trying to do that in the dbus extension as an option, so it wouldn't be linked if it wasnt possible.
If the libxml DOM interface could be implemented on top of the Inkscape XML api that would work but I don't know how difficult that would be.
Also writing an xpath processor is to much work for my use-case. It would be easier to achieve by scripting or by an extension or something.
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
On Jun 18, 2011, at 11:57 AM, joakim@...1974... wrote:
Jasper van de Gronde <th.v.d.gronde@...528...> writes:
BTW, I'm assuming that you would be writing your own XPath processing code (perhaps not necessarily the parser, but at least the part that finds the required nodes). If you meant to reuse an existing library you can probably forget about it (unless it's set up in an extremely flexible manner).
Well, I was thinking of using the xpath implementation in libxml2 since that is linked already. And I was trying to do that in the dbus extension as an option, so it wouldn't be linked if it wasnt possible.
If the libxml DOM interface could be implemented on top of the Inkscape XML api that would work but I don't know how difficult that would be.
Also writing an xpath processor is to much work for my use-case. It would be easier to achieve by scripting or by an extension or something.
If you are interested in pursing this from a user/tester viewpoint, this is exactly something that has been targeted for a revised extensions API. The best route would be to expose a live DOM to extensions instead of the current "read-from-stdin, process, write-to-stdout" approach. Having someone with a need and willing to give feedback is the best way to help me or others actually write the code.
It also matches a need I have for adding dynamic validation and feature subset warnings (e.g. warn that you are using an unsupported SVG feature when doing a work that targets SVG Tiny). That would involve a simple pair of an XPath expression to find the SVG nodes to test followed by a simple true/false XPath expression to test each found node with.
For the implementation side of things, it might be possible to hook up to libxml2, or it might be quite difficult. The good news is that if a re-write for Inkscape is needed, then I should be able to knock that out without too much difficulty. In the past I've built both DOM and XPath libraries from scratch for hand-held blackberry applications. Especially since we're talking just selecting items, not full xslt, it is a much more manageable problem.
Jon Cruz <jon@...18...> writes:
On Jun 18, 2011, at 11:57 AM, joakim@...1974... wrote:
Jasper van de Gronde <th.v.d.gronde@...528...> writes:
BTW, I'm assuming that you would be writing your own XPath processing code (perhaps not necessarily the parser, but at least the part that finds the required nodes). If you meant to reuse an existing library you can probably forget about it (unless it's set up in an extremely flexible manner).
Well, I was thinking of using the xpath implementation in libxml2 since that is linked already. And I was trying to do that in the dbus extension as an option, so it wouldn't be linked if it wasnt possible.
If the libxml DOM interface could be implemented on top of the Inkscape XML api that would work but I don't know how difficult that would be.
Also writing an xpath processor is to much work for my use-case. It would be easier to achieve by scripting or by an extension or something.
If you are interested in pursing this from a user/tester viewpoint, this is exactly something that has been targeted for a revised extensions API. The best route would be to expose a live DOM to extensions instead of the current "read-from-stdin, process, write-to-stdout" approach. Having someone with a need and willing to give feedback is the best way to help me or others actually write the code.
It also matches a need I have for adding dynamic validation and feature subset warnings (e.g. warn that you are using an unsupported SVG feature when doing a work that targets SVG Tiny). That would involve a simple pair of an XPath expression to find the SVG nodes to test followed by a simple true/false XPath expression to test each found node with.
For the implementation side of things, it might be possible to hook up to libxml2, or it might be quite difficult. The good news is that if a re-write for Inkscape is needed, then I should be able to knock that out without too much difficulty. In the past I've built both DOM and XPath libraries from scratch for hand-held blackberry applications. Especially since we're talking just selecting items, not full xslt, it is a much more manageable problem.
I would clearly like to help out with this. It would be vey useful for my use-cases. Your plan also seems much more fleshed out than mine.
BTW my immediate need, which is importing a svg file via dbus and modifying the result slightly, seems to be solvable by using the new dbus important function and the dbus tree traversal functions to find the apropriate child nodes to change.
participants (4)
-
unknown＠example.com -
Jasper van de Gronde -
Jon Cruz -
Krzysztof Kosiński