Auto-update clones of linked bitmap images when linked image was changed on disk

[su_v]

I have an svg that contains some imported bitmaps as objects.
All of them are linked, not embedded. Additionally most have clones.
I am now looking for the best way to make Inkscape update the svg
whenever the sources have changed.
If I quite and reload the file, it works perfectly., but i hope there is a faster
way to di it.
Thanks in advance.

(originally filed as question:
<https://answers.launchpad.net/inkscape/+question/167214>)

[su_v (suv-lp)]

Which Inkscape version on which OS/platform do you use?

Inkscape does auto-reload externally edited linked bitmap images since 0.47:
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Editing_bitmaps_in_an_external_editor>
(supported on Linux, Windows and Mac OS X).

I can confirm though that the clones are not auto-updated as well and still display the original version of the linked bitmap image. There seems to be no way within Inkscape to trigger the update (bar from duplicating or copy&pasting the clone). Not even relinking the clone to the copied bitmap image after the auto-update does trigger an update of the image displayed by the clone, nor does opening a duplicate window on the same file (menu 'View > Duplicate Window').

(Tested with Inkscape 0.48.1 and 0.48+devel r10530 on Mac OS X 10.5.8).

Converting the question into a bug report - there should be either a way to manually trigger the update of clones of linked images beyond saving & reverting or saving & reloading the SVG file, or the auto-update function of the linked image needs to search the file for possible clones (and clones of clones …) of the updated image and refresh their content, too.

[Astuur (wolfsteinmetz)]

My initial question and the following remarks pertain to Inkscape 0.48+devel r10508 on 32bit WinXP SP3 system.

Further testing has shown:
My installation behaves differently from what ~suv found, in that
I do not find the bug that he describes.
In particular, I cannot confirm any difference in behavior between the linked
image and its clones.

It seemes, that a grouping or ungrouping process that pertaines to all objects (linked image and all clones) will reliably update the content of the objects.

Steps to reproduce:
1) Create a 64x64 pixel 16 paletted bitmap in an exterior program.
2) Keep it open and save the bitmap to disk as png.
3) Open Inkscape and import this png as "linked".
4) Create tiled clones (6x6) and form one group of all this.
5) Save this svg to disk. Keep Inkscape open.
6) Change the picture in the external bitmap editor. Save to disk.
7) Back in Inkscape, verify that no update has occured.
8) Now ungroup the group of 6x6.

---> the content of each tile is updated.

9) repeat step 6 and 7
10) Now re-group all the tiles.

---> again an update occurs.

I have been able to repeat the process 5 times.
An update of the contents also occurs when you duplicate the objects,
but only the duplications show the new content, which may be a bug of its own.

I am unsure what behaviour I should expect from Inkscape.
If the content is supposed to update automatically without doing any particular
action in Inkscape, it does not work as expected.

If an update is triggered by certain actions in Inkscape, I'd like to suggest a new
command that does nothing else but upgrade all linked and cloned objects.

Thank you for the fine work and your immediate reaction to my question!

[su_v (suv-lp)]

> (…) in that I do not find the bug that he describes.

There seems to have been misunderstandings - AFAIU in my comment I describe the same issue (clones of linked bitmap images are not updated when the image has changed on disk) as you do (including the update when duplicating the clone), just that I missed the new workaround with grouping.

> In particular, I cannot confirm any difference in behavior
> between the linked image and its clones.

Did you consider that with limiting the tests to tiled clones, you don't have the original linked image visible to check whether it gets auto-updated when changed on disk externally? The original tile (linked image) is hidden below the first clone in the upper left corner.

Please test with a linked bitmap image and a manually created clone (Alt+D) moved aside to not overlap the original (if the image itself is not auto-updated on Windows, Bug #357646 “Linked image not updated” needs to be reopened IMHO).

Thanks for discovering the workaround to group or ungroup clones to trigger an update of their content.

[Astuur (wolfsteinmetz)]

Ah .. you're right of course. It is as you described. The linked images are updated automatically, the clones are not.
I did not know about the "covered" original. I thought the linked file was
itsself included in the field of tiles. For this reason, I said, that I witness a different behavior.
It might be a good idea to introduce an easy way to discern the one from the other. (linked from clones).

I'm sorry about the confusion.
You should not file bug reports, when you're just 3 days into discovering the program :)
Thanks for your explanations.