extension 'Layers as Seperate SVG' saves only a single layer

[Alvin Penner]

also, 'Seperate' should be spelled 'Separate'.

attached is the original svg file, with 2 layers

[Alvin Penner (apenner)]

attached is the tar file produced

[Alvin Penner (apenner)]

attached is the single svg file obtained from the tar file.

- I was not exactly sure what to expect, but I think I expected 2 files, not one.
- also the single svg file produced, does not have a time stamp, which is very unusual
- also the svg file cannot be opened in my normal XML editor, I get a syntax error
- also, Inkscape 0.48.4 refuses to open this svg file

these may be deficiencies in my zip program, Winzip 6.3, any recommendations on which program to use (?), since this is not a normal zip format on Windows

[su_v (suv-lp)]

Works as expected on OS X 10.7.5, r13084.

[su_v (suv-lp)]

AFAICT the tar file generated on Windows is corrupted:

$ tar -tvf 1286524-Layertest.tar
-rw-r--r-- 0 root root 2410 Jan 1 1970 Layer 1.svg
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Truncated tar archive
tar: Error exit delayed from previous errors.
$

[su_v (suv-lp)]

On Ubuntu 13.10, new tarfile exported with r13084: tar complains about the time stamp, but extracts the files nevertheless:

$ tar -tvf 1286524-Layertest-r13084.tar
-rw-r--r-- 0/0 2427 1970-01-01 01:00 Layer 1.svg
-rw-r--r-- 0/0 2412 1970-01-01 01:00 Layer 2.svg
$ tar -xvf 1286524-Layertest-r13084.tar
Layer 1.svg
tar: Layer 1.svg: implausibly old time stamp 1970-01-01 01:00:00
Layer 2.svg
tar: Layer 2.svg: implausibly old time stamp 1970-01-01 01:00:00
$

[Alvin Penner (apenner)]

yes, there appears to be a difference between the tar file I got on Windows and the tar file you got on OSX.
I used Winzip 6.3 to open your file 1286524Layertest-osx.tar and I got two svg files and they both opened normally in Inkscape.

[su_v (suv-lp)]

Here's the one created on Ubuntu 13.10 (VM, 64bit).

[Alvin Penner (apenner)]

thanks, that also appears to work well here on Windows, when I unpack it with Winzip, and get 2 files.

[Alvin Penner (apenner)]

just for fun, I put a tracer into the Python code to see if both layers are actually being processed. The code contains a branch depending on whether this is the first layer or a subsequent layer.

if previous != None:
    inkex.errormsg("add new = " + name)
    template.getroot().replace(previous, layer)
else:
    inkex.errormsg("add org = " + name)
    template.getroot().append(layer)

The tracer indicated that both branches were executed and that both layers were encountered, but apparently the second layer was subsequently lost somewhere.

[Martin Owens (doctormo)]

I've pushed fixes for both the mtime and spelling mistake; but the windows issue is a mystery. There's not excepts catching errors so if we're not getting an error, it must be the python tarfile module.

[Alvin Penner (apenner)]

I just ran the new version on Windows XP. I get the following Python error message:

Traceback (most recent call last):
  File "tar_layers.py", line 114, in <module>
    e.affect()
  File "C:\InkscapeBZR\inkscape\share\extensions\inkex.py", line 261, in affect
    self.effect()
  File "tar_layers.py", line 109, in effect
    tar.addfile(**self.io_document(name, template))
  File "tar_layers.py", line 90, in io_document
    info.mtime = int(datetime.now().strftime('%s'))
ValueError: invalid literal for int() with base 10: ''

[Alvin Penner (apenner)]

attached is a slightly modified version of tar_layers.py. This version will produce an uptodate time stamp for the individual files on Windows XP.
Unfortunately, the tar file itself is still corrupt on Windows. It appears that the problem is related to the use of the CR/LF combo on Windows, instead of just a single CR.

[Alvin Penner (apenner)]

attached is an improved version of the previous fix. This version will produce a correct tar file on Windows, by modifying the mode of sys.stdout. The Windows-specific fix was borrowed from jessyInk_export.py.

I wonder if this could be tested on a non-Windows platform to confirm that nothing has been broken?

[su_v (suv-lp)]

Modified version of the python script (comment #14) tested successfully on OS X 10.7.5 (inkscape trunk r13113, Python 2.7.6, locale en_US.UTF-8).

[Alvin Penner (apenner)]

thanks, committed to rev 13123

[Martin Owens (doctormo)]

Good fix, thanks for testing on windows. Impossible this end.

[Alvin Penner (apenner)]

no problem, the code was actually borrowed from jessyInk_export.py. I guess they ran into the same issue when generating zipfiles.