[scribus] SVG files: can I force a refresh or reload?

[Barry McKenna]

I have a two page .sla file, each page with 7 SVG imported 
files. (.sla = 46MB)

I had to perform some minor editing before actually loading 
each file, and then each file had to be positioned exactly 
on x and y in the Properties dialog.

It took me about two hours to finish the task.

About 2/3 of the way through, I realized that the title text 
for each SVG needed to have its x-pos slightly adjusted.

I presumed that after completely loading and positioning all 
14 SVG files, and then saving and closing the .sla file, 
that I could then go back and edit the SVG files title's 
x-pos for the first 2/3rds which had the earlier title text 
x-pos, and that my problem would be solved because - and 
this is the catch, I guess - we all know that when we open 
an .sla file that has graphics, the .sla is relying on the 
graphics files being in the same directory that they were 
originally loaded from.

Right?

So, I presumed that when I re-opened the Scribus .sla file 
that referenced the SVG files, that it would reload them - 
now with required slight editing - from the original 
directory, and the editing of the SVG files would be 
reflected in the re-opened Scribus .sla file.

But, unfortunately, even though the SVG files have been 
edited, the re-opened Scribus file is still reflecting the 
original x-pos for SVG's title text.

So, now my first question is, is there a different treatment 
with SVG files, such as that they actually get stored in the 
.sla file and they are not referenced to the original 
directory that they are originally imported from, like 
importing a .png or a .jpg into a frame?

...or what?

Is there a way that I can get the .sla file to reflect the 
edits to the SVG's text x-pos without deleting them all and 
then spending another hour and half re-opening them and 
positioning them?

(This is not a complaint: if I have to, I have to. But if 
the SVGs are actually stored in the .sla file, unlike other 
graphics formats, then that should probably be identified in 
the wiki and the next edition of the manual, that is, if 
it's not already there somewhere, and I just haven't located 
it...)

Barry McKenna