Hey Devs,
I've been looking into this bug:
https://bugs.launchpad.net/inkscape/+bug/1269880
And have forged a solution in uri-references.cpp by using the existing getPath property and GLib's build_filename. See the commit here:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12939
I really didn't expect this to work, I thought it'd be step one in a chain of items to fix. But it actually works and I'd like other dev's input to see if it's doing the right thing.
I'd like to have a document based list of linked documents, so they could be tracked (and maybe ui'ed in the future). But I'm not sure if it's even needed. Thoughts?
Best Regards, Martin Owens
1. Please adhere to the coding style... http://www.inkscape.org/en/develop/coding-style/ Specifically, there's wrong spacing around 'if' and the variable names are incorrect. I know this is pedantic but it makes reading the code later much easier.
2. The fix itself looks OK. A more advanced solution would be to resolve an absolute path to which the reference points (this is probably already done somewhere in this code) and keep a cache of read-only SPDocument for each ref, either on the top-level Inkscape object or in the SPDesktop object, so that each referred image has its SP tree constructed only once.
3. Does this also solve the problem of svg:image rasterizing the contents of referred SVG images?
Regards, Krzysztof
On Sun, 2014-01-19 at 00:33 +0100, Krzysztof Kosiński wrote:
- Does this also solve the problem of svg:image rasterizing the
contents of referred SVG images?
Not yet. I'm working on how to make sp-image.cpp have that capability. I've already disabled linux-only/librsvg rendering since that's a toxic workaround. But I am committed to get it working for 0.91
Now we take the filename and get the same document object node and make sp-image behave like sp-use. What's your thoughts on the best way of duplicating this behavior without copy and pasting lots of code.
Martin,
2014/1/19 Martin Owens <doctormo@...400...>:
On Sun, 2014-01-19 at 00:33 +0100, Krzysztof Kosiński wrote:
- Does this also solve the problem of svg:image rasterizing the
contents of referred SVG images?
Not yet. I'm working on how to make sp-image.cpp have that capability. I've already disabled linux-only/librsvg rendering since that's a toxic workaround. But I am committed to get it working for 0.91
Now we take the filename and get the same document object node and make sp-image behave like sp-use. What's your thoughts on the best way of duplicating this behavior without copy and pasting lots of code.
Maybe a common base class for SPImage and SPUse?
There are some important differences though, e.g. SPImage does not inherit any style, it creates a new viewport, and it can't refer to single elements.
Regards, Krzysztof
On 20-1-2014 19:26, Krzysztof Kosiński wrote:
2014/1/19 Martin Owens <doctormo@...400...>:
On Sun, 2014-01-19 at 00:33 +0100, Krzysztof Kosiński wrote:
- Does this also solve the problem of svg:image rasterizing the
contents of referred SVG images?
Not yet. I'm working on how to make sp-image.cpp have that capability. I've already disabled linux-only/librsvg rendering since that's a toxic workaround. But I am committed to get it working for 0.91
Now we take the filename and get the same document object node and make sp-image behave like sp-use. What's your thoughts on the best way of duplicating this behavior without copy and pasting lots of code.
Maybe a common base class for SPImage and SPUse?
There are some important differences though, e.g. SPImage does not inherit any style, it creates a new viewport, and it can't refer to single elements.
Just an idea. Instead of forcing it into inheritance structure, a templated function perhaps? (so to do not duplicate written code, and have possibly "duplicated" generated code)
cheers, Johan
On Mon, 2014-01-20 at 19:26 +0100, Krzysztof Kosiński wrote:
Maybe a common base class for SPImage and SPUse?
There are some important differences though, e.g. SPImage does not inherit any style, it creates a new viewport, and it can't refer to single elements.
Interesting. So with the way Inkscape::URIReference is overlaid with Inkscape::UseReference but both consume Inkscape::URI which does the filename/object id referencing.
I'm not sure if the image work should or should not be done separately anyway if the way they're specified is so different.
Martin,
participants (3)
-
Johan Engelen -
Krzysztof Kosiński -
Martin Owens