svg property "sodipodi:docname" is not updated when saving file as a new name

[Alvin Penner]

- Inkscape rev 11519
- open Inkscape
- open a file called "drawing.svg"
- note that the Inkscape form title says "drawing.svg" as expected
- in the XML editor the svg tag has a property called sodipodi:docname = "C:\Windows\Temp\drawing.svg" as expected
- now perform a File->Save As "Drawing2.svg"
- note that the Inkscape form title changes to "drawing2.svg" as expected
- however, the XML editor still has the original sodipodi:docname, not updated
- close Inkscape
- open the file drawing2.svg with a text editor and confirm that sodipodi:docname = "C:\Windows\Temp\drawing.svg", not updated
- double-click on the file Drawing2.svg to open it in Inkscape
- note that, after it opens, the XML editor now shows sodipodi:docname = "C:\Windows\Temp\drawing2.svg which is consistent with the Inkscape form title.

- it appears the sodipodi:docname is getting updated on a File->Open but is not updated on a File->Save As...

[su_v (suv-lp)]

Not reproduced with Inkscape 0.46 on Mac OS X 10.5.8
Reproduced with Inkscape 0.47 and later versions on Mac OS X 10.5.8 and OS X 10.7.4-

This part I cannot reproduce:
> - in the XML editor the svg tag has a property called
> sodipodi:docname = "C:\Windows\Temp\drawing.svg" as expected

I never see an absolute path in the 'sodipodi:docname' attribute (not even in Inkscape 0.46 [1]). How was the original file 'drawing.svg' created?

---
[1] AFAIK, there used to be an attribute 'sodipodi:docbase' which held the absolute path, but this was removed before the release of Inkscape 0.46 (see bug #230543 comment #2).

[su_v (suv-lp)]

Possibly related:
- Bug #243162 "docname incorrectly set in 0.46 in output extension"
  <https://bugs.launchpad.net/inkscape/+bug/243162>

See comment #2 in bug #243162 which states the same as reported here:
«Old file name is used in sodipodi:docname attribute when file saved with Save As.»

[Alvin Penner (apenner)]

> I never see an absolute path in the 'sodipodi:docname' attribute

as far as I can tell, on Windows, this always shows up as an absolute path.
I am attching a demo file where I have completely removed the attribute sodipodi:docname since it does not appear to be used when loading a file.
when I load this file I get an absolute path for sodipodi:docname.

[Alvin Penner (apenner)]

I take that back, partially...

there is a case where I can see a relative filename:
use the DOS command:

C:\Windows\Temp>"\Program Files\Inkscape\Inkscape" nametest.svg

in this case the 'sodipodi:docname' is just the file name 'nametest.svg', nothing else. I very rarely use this syntax in practice.
I would normally use the following syntax, which leads to an absolute path in 'sodipodi:docname'

C:\Program Files\Inkscape>inkscape \windows\temp\nametest.svg

when I use the gui to open the file then I always get an absolute path reference

[Alvin Penner (apenner)]

on second thought, marking this as a duplicate of Bug 243162, since it appears to be identical to comment 1 in that bug,

[su_v (suv-lp)]

I'm not sure the original report in Bug 243162 is really identical - AFAIU it was about having the filename of the tmp file (which is passed to output extensions) stored in the tmp file (e.g. sodipodi:docname="ink_ext_XXXXXX8SRLDU" ). Possibly this only happened (or still happens) on Windows, and does not affect other platforms.

AFAIU comment #1 in bug #243162 actually describes what happens in 0.47 and later versions (and what you reported here): the output SVG file keeps the old sodipodi:docname attribute (from the original file), and the new file name (as entered in the file dialog) is only updated as current 'sodipodi:docname' the next time the document is loaded in Inkscape.

One underlying problem though still exists AFAIU, either way: script-based output extensions don't know the _new_ file name their output will be saved under (the one that the user entered in the file dialog).

[Alvin Penner (apenner)]

yes, it is probably just as well to leave these as separate issues.

<Offtopic>In any event, my attempt to mark this as a duplicate failed miserably, so after trying for about 10 minutes or so, I gave up and decided to mow the lawn instead. This website in its new improved form is proving to be absolutely devastating for my blood pressure, I may have to 'up' my meds
</OffTopic>

[su_v (suv-lp)]

On 14/07/2012 16:48, ~suv wrote:
> I'm not sure the original report in Bug 243162 is really identical -
> AFAIU it was about having the filename of the tmp file (which is passed
> to output extensions) stored in the tmp file (e.g.
> sodipodi:docname="ink_ext_XXXXXX8SRLDU" ). Possibly this only happened
> (or still happens) on Windows, and does not affect other platforms.

I can actually reproduce this with Inkscape 0.46 (on Mac OS X 10.5.8), so it doesn't seem to be a win32-specific issue, and has been fixed in 0.47 (and later versions).

Probably bug #243162 could be closed as 'Fix Released' and what was confirmed in comment #1 getting tracked in this report.

[Alvin Penner (apenner)]

I think Bug 243162 still exists

- start Inkscape rev 11519
- load file text.svg
- confirm that sodipodi:docname = C:\WINDOWS\Temp\text.svg as expected
- now select something and run the Extension->Color->Darker or something
- confirm that sodipodi:docname = C:\DOCUME~1\Alvin\LOCALS~1\Temp\ink_ext_XXXXXX.svgWWTQHW

- this is not expected. It is conceivable that there may be some purpose in passing the temporary filename to a Python extension, however, I would hope that the sodipodi:docname would revert back to the original value after the extension is complete. Basically I think what I would like to see is that the sodipodi:docname should always be the same as the title in the Inkscape frame.

[su_v (suv-lp)]

> run the Extension->Color->Darker or something

I commented about this being different for _effect_ extensions: in my tests, the 'sodipodi:docname' gets changed later on in the current document window (the XML Editor in the current document shows the tmpfile filename as docname after the extension was applied, but it gets reverted to the current document name on save). The file that is passed to the extension script (i.e. the copy in the tmp directory) still has the original 'sodipodi:docname' attribute, and the effect script extension thus has access to the original file name). Why in the process of piping the SVG content back to the current document window the docname attribute gets changed, I don't know. But AFAICT it happens after the script has finished, and it is different from what happened in Inkscape 0.46 with _output_ extensions.

[Alvin Penner (apenner)]

that's true, I guess all I was trying to say is that there are two separate issues here, neither of which has been fixed.
- in one case, which is the File->Save As... case, we have an instance of a svg property which is not getting updated when it should have been updated.
- in the other case, which is the Extension->Effects menu we have the opposite case where this property is being updated when it should not have been updated

[su_v (suv-lp)]

Attaching the extensions I used for testing (unfortunately, the two relevant ones (ShellWrapper-*.inx) are using a shell script which won't work on Windows (this is due to my utter lack of python-fu)). Note: use with test files only - the shell script will replace the existing content (after parsing the information and the tmp file passed to it), both when run as effect as well as when run as output extension.)

AFAIU the two issues (output, effects) ought to be tracked separately (but related [1]) ;)

---
[1] launchpad.net is planning to add bug relations as new feature)

[su_v (suv-lp)]

zip archive updated (added correct namespace declarations to ShellWrapper.sh)

[su_v (suv-lp)]

On 14/07/2012 15:17, Alvin Penner wrote:
> as far as I can tell, on Windows, this always shows up as an absolute
> path. I am attching a demo file where I have completely removed the
> attribute sodipodi:docname since it does not appear to be used when
> loading a file. when I load this file I get an absolute path for
> sodipodi:docname.

Must be a Windows-specific thing: can't reproduce with command-line version nor with one packaged for OS X ('sodipodi:docname' always contains just the file name, no path information).

[su_v (suv-lp)]

<off-topic>
Alvin Penner wrote 4 hours ago:
> I would normally use the following syntax, which leads to an
> absolute path in 'sodipodi:docname'
>
> C:\Program Files\Inkscape>inkscape \windows\temp\nametest.svg
>
> when I use the gui to open the file then I always get an absolute
> path reference.

Odd - I grepped through ~3000 SVG files I have downloaded over time from the bug tracker:
- 4 files have an absolute path name starting with 'C:' in 'sodipodi:docname'
- 23 files have an absolute path name starting with 'C:' in 'sodipodi:docbase'
- 673 files have an absolute path name starting with 'C:' in 'inkscape:export-filename'

I would have expected many more files with 'C:' in 'sodipodi:docname' among those 3000 user files, if it is the default on Windows when using the GUI to always include the full path in addition to the file name.
</off-topic>

[Alvin Penner (apenner)]

> I would have expected many more files with 'C:' in 'sodipodi:docname'

yes, I have checked on both Inkscape 0.47.1 and also recent trunk version, and in both cases the normal behaviour is that the saved file will have just the filename in sodipodi:docname while the XML editor in the loaded file will have the full path name and the Inkscape frame title will be just the file name, no path.

After fooling around with this all day, I have seen only two instances that do not follow this rule, and neither of these was reproducible, I do not know how it happened. Unfortunately one of those instances was the very first post I submitted, which had an absolute path in the svg file, but I cannot reproduce that.

[Alvin Penner (apenner)]

fix committed to rev 11562.

<offtopic>
on Windows this has a bit of a side-effect. Previously the sodipodi:docname in Windows could be either absolute or relative depending on the history. On the initial Load command, the sodipodi:docname would be an absolute reference, and then on subsequent saves it would turn into a relative filename. Now it is always relative, as far as I can tell.
</offtopic>

[Phil Siviter (philsiviter)]

I have just observed this bug in v0.92 on Windows 10.

i.e., sodipodi:docname not updated following "Save As ...".

I noticed when the svg file appeared blank when I upload it to my WordPress site library. The previous version of the file had uploaded without problem so I compared the two versions and saw the incorrect filename. After manually editing it the file uploaded to the library without problem.

[Phil Siviter (philsiviter)]

Sadly, I cannot reproduce this behaviour, but it definitely occurred :{

Incidentally there was/is no path, just the filename.