docname incorrectly set in 0.46 in output extension

Bug #243162 reported by Jan-Piet Mens on 2008-06-26
2
Affects Status Importance Assigned to Milestone
Inkscape
Low
Unassigned

Bug Description

On Win32, during Save/Save-As/Save-a Copy, defined "output" extensions are invoked with argv[1] containing the name of a temporary file which contains the SVG. The XML in that, has the attribute sodipodi:docname set to the name of the temporary file instead of the name the user wanted to save the file as (e.g. sodipodi:docname="ink_ext_XXXXXX8SRLDU" instead of sodipodi:docname="bb01.jp"). This means that the extension has no way of determining what the file's name (or sodipodi:docbase) is.

Problem occurs in 0.46 and in Inkscape0806231729.7z.

On Linux (can only test 0.43) the handling is correct: sodipodi:docname contains the document name.

Extensions that want to "do" something with the file (e.g. copy it somewhere, create archives, etc.) can't because they don't know what the filename is.

Tavmjong Bah (tavmjong-free) wrote :

Old file name is used in sodipodi:docname attribute when file saved with Save As.
Seen on linux with latest SVN update (r21820).

Changed in inkscape:
status: New → Confirmed
jazzynico (jazzynico) on 2011-02-01
Changed in inkscape:
importance: Undecided → Low
tags: added: exporting saving
Alvin Penner (apenner) wrote :

just writing to re-confirm both the original report and also comment 1, on Windows XP, Inkscape 11519

su_v (suv-lp) wrote :

Original report:
Not confirmed with Inkscape 0.48+devel r11548 on OS X 10.7.4 for _output_ extensions (the auto-generated filename of the tmp file is not used as its 'sodipodi:docname' - the file in $TMPDIR has the old name of the document that is being saved as in 'sodipodi:docname').

Comment #2:
Confirmed with Inkscape 0.48+devel r11548 on OS X 10.7.4 (see also recent bug #1024690).

On OS X, AFAICT the original report (tmp filename used for 'sodipodi:docname') it is true for _effect_ extensions though, called from Inkscape's 'Extensions' menu.

su_v (suv-lp) wrote :

> On OS X, AFAICT the original report (tmp filename used for 'sodipodi:docname')
> it is true for _effect_ extensions though, called from Inkscape's 'Extensions' menu.

Correction: The statement was not accurate - it only occurs in a badly-constructed test case where the effect extension (a shell script) returns a completely new SVG content without specifying a 'sodipodi:docname' attribute (the returned content is based on parsing the arguments passed to the test extension and parts of the content of the original tmpfile).

su_v (suv-lp) wrote :

Another correction:
> Comment #2:
> Confirmed with Inkscape 0.48+devel r11548 on OS X 10.7.4 (see also recent bug #1024690).

This was of course referring to comment #1.

Alvin Penner (apenner) wrote :

a partial fix has been committed to bzr rev 11574.
when running an effect from the Extensions menu, the sodipodi:docname will no longer be overwritten with the temporary filename,

Alvin Penner (apenner) wrote :

@Jan-Piet, could you re-test with current build and see if this problem still exists?

attached is the behaviour I am getting:

- save a file as testold.svg
- in the XML editor confirm that sodipodi:docname = testold.svg
- run a Python output extension such as Desktop Cutting Plotter dxf
- choose Save As... filename as testnew.dxf
- in the Python output script interrogate the argv variable and confirm that it contains the temporary filename as expected.
- in the same Python output script, interrogate sodipodi:docname and confirm that it is testnew.dxf

- this last behaviour is different compared to Inkscape 0.48.3.1

Changed in inkscape:
status: Confirmed → Incomplete
Kris (kris-degussem) wrote :

Closing report by lack of user feedback.
Feel free to reopen the bug if the problem reappears.

Changed in inkscape:
status: Incomplete → Fix Committed
milestone: none → 0.49
Bryce Harrington (bryce) on 2015-02-21
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers