Save and Open as .ZINK (was zip with images)
Hi,
I enhanced the first extension, which was able to save a zip archive with svg and images, with an extra extension which is able to read the archive instantly. I changed the zip-extention to .zink which is of course a combination of Zip and Inkscape.
The output extension creates a zip and makes all image hrefs relative. The input extension does the reverse: it unpackes the zip and before printing the doc to stout it replaces all image hrefs with the exact path of the temp dir.
The svg in the archive is named content.svg so its easy to open. Of course a file with metadata can be packed be also, but I wanted quick results and I don't really know what to store in such a manifest because everything is said in the svg.
It works rather smooth. You won't notice that this is not the native file format. You can open a .zink make changes and click CTRL-S so it save the .zink-file again.
Please download and test it on different platforms. http://facility.lingewoud.nl/hacks/inkscape_save_and_open_as_zink/
You can also download the example .zink which you must be able to open after installing the extensions.
Hope you like it.
Pim
Pim Snel wrote:
... Please download and test it on different platforms. http://facility.lingewoud.nl/hacks/inkscape_save_and_open_as_zink/
I tried it on win32, it didn't quite work for me yet:
I had to remove the python dependency from the .inx file for the input plugin, probably because I don't have python in my path. It is perfectly able to run python scripts though, because the python installer has set it up so that they're run with python.
When trying to open the example.zink it complains about a bad CRC for some file, but according to Winrar nothing is wrong: ------------ Traceback (most recent call last):
File "share\extensions\zink_input.py", line 108, in ?
e.affect()
File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 90, in affect
self.effect()
File "share\extensions\zink_input.py", line 83, in effect
self.unzip(stream,tmp_dir)
File "share\extensions\zink_input.py", line 72, in unzip
result.write( z.read( f.filename ) )
File "C:\Python24\lib\zipfile.py", line 368, in read
raise BadZipfile, "Bad CRC-32 for file %s" % name
zipfile.BadZipfile: Bad CRC-32 for file logo.png ------------
When trying to save a zink file I get the following error: ------------ Traceback (most recent call last):
File "share\extensions\zink_output.py", line 112, in ?
e.affect()
File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 90, in affect
self.effect()
File "share\extensions\zink_output.py", line 55, in effect
ctx_orig = inkex.xml.xpath.Context.Context(self.document,processorNss=inkex.NSS)
AttributeError: 'module' object has no attribute 'NSS' ------------
Op vrijdag 2 december 2005 12:58, schreef Jasper van de Gronde:
I tried it on win32, it didn't quite work for me yet:
I had to remove the python dependency from the .inx file for the input plugin, probably because I don't have python in my path. It is perfectly able to run python scripts though, because the python installer has set it up so that they're run with python.
I will remove this. It works without. Thanks
When trying to open the example.zink it complains about a bad CRC for some file, but according to Winrar nothing is wrong:
Traceback (most recent call last):
File "share\extensions\zink_input.py", line 108, in ?
e.affect()File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 90, in affect
self.effect()File "share\extensions\zink_input.py", line 83, in effect
self.unzip(stream,tmp_dir)File "share\extensions\zink_input.py", line 72, in unzip
result.write( z.read( f.filename ) )File "C:\Python24\lib\zipfile.py", line 368, in read
raise BadZipfile, "Bad CRC-32 for file %s" % namezipfile.BadZipfile: Bad CRC-32 for file logo.png
This seems to be a python bug on windows but I don't know for sure. I must investigate more on this. No solution for it yet.
When trying to save a zink file I get the following error:
Traceback (most recent call last):
File "share\extensions\zink_output.py", line 112, in ?
e.affect()File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 90, in affect
self.effect()File "share\extensions\zink_output.py", line 55, in effect
ctx_orig =inkex.xml.xpath.Context.Context(self.document,processorNss=inkex.NSS)
AttributeError: 'module' object has no attribute 'NSS'
As I expected, your inkex.py is to old. Replace it with the one from CVS or with the one you can download from http://facility.lingewoud.nl/hacks/inkscape_save_and_open_as_zink/
After this saving to zink works.
Pim
Thank you all for your feedback. I've made the following mini roadmap/todo list for making the .zink format mature and widely accepted in the inkscape user and developer base.
1. Make the current extension work on Inkscape CVS in mac os x and windows 2. Add file containing zink version number for future backwards compatibility. 3. Write documentation and specs and keep up to date. I have setup the wiki page at http://wiki.inkscape.org/cgi-bin/wiki.pl?ZINK_Filetype 3. Implement a proper temp directory solution with the help of other inkscape programmers 4. Investigate howto reinplement all functionallity in c++ using the existing inkjar code.
Pim
On Fri, 2 Dec 2005, Pim Snel wrote:
Date: Fri, 2 Dec 2005 01:07:28 +0100 From: Pim Snel <pim@...810...> To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Save and Open as .ZINK (was zip with images)
Hi,
I enhanced the first extension, which was able to save a zip archive with svg and images, with an extra extension which is able to read the archive instantly.
I changed the zip-extention to .zink which is of course a combination of Zip and Inkscape.
It is very catchy and memorable but using .Zip or .Jar would give a better chance of keeping things interoperable with existing tools.
The svg in the archive is named content.svg so its easy to open. Of course a file with metadata can be packed be also, but I wanted quick results and I don't really know what to store in such a manifest because everything is said in the svg.
If I remember correctly the manifest tends to be redundant but this is intentional for fast, easy, and predictable access to this valuable information.
The format of the manifest is deliberately kept simple so all kinds of parsers and scripts and other third part tools can get at it easily. A Zip file can contain many files with different compression values, the manifest could often be left uncompressed whereas other files would be heavily compressed. I've always been impressed by how well thought out Jar files were (at least the modern incarnation OpenDocument uses).
It works rather smooth. You won't notice that this is not the native file format. You can open a .zink make changes and click CTRL-S so it save the .zink-file again.
Please download and test it on different platforms. http://facility.lingewoud.nl/hacks/inkscape_save_and_open_as_zink/
You can also download the example .zink which you must be able to open after installing the extensions.
Sounds really great, I'm sure users will love this new feature. Thanks again.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
P.S. Sorry I didn't know enough about inkjar files to suggest anything helpful, which is why I didn't respond to your previous mail.
This is really cool. I'm glad that you got it working as input and output extensions.
On Fri, 2005-12-02 at 01:07 +0100, Pim Snel wrote:
I enhanced the first extension, which was able to save a zip archive with svg and images, with an extra extension which is able to read the archive instantly. I changed the zip-extention to .zink which is of course a combination of Zip and Inkscape.
I'd agree with Alan here. I think that ".svg.zip" would probably be better. This would probably assist in interoperability with other tools and will make users understand what they have better.
One thing that I'm curious about, is how we can clean up from the input extension. It sounds like it leaves the files in the temporary directory, which makes sense, but I'd like to be "good citizens" and clean up after ourselves. Does anyone have any ideas on this?
--Ted
Op maandag 5 december 2005 08:12, schreef Ted Gould:
This is really cool. I'm glad that you got it working as input and output extensions.
Unfortunately, not yet on Windows :(
On Fri, 2005-12-02 at 01:07 +0100, Pim Snel wrote:
I enhanced the first extension, which was able to save a zip archive with svg and images, with an extra extension which is able to read the archive instantly. I changed the zip-extention to .zink which is of course a combination of Zip and Inkscape.
I'd agree with Alan here. I think that ".svg.zip" would probably be better. This would probably assist in interoperability with other tools and will make users understand what they have better.
There is one advantage in giving it its own extension. The system can register this as mime type and automaticly open inkscape when it sees a *zink.
But I don't have any problems with the .svg.zip extension, so if you all agree I will change it to .svg.zip.
One thing that I'm curious about, is how we can clean up from the input extension. It sounds like it leaves the files in the temporary directory, which makes sense, but I'd like to be "good citizens" and clean up after ourselves. Does anyone have any ideas on this?
I don't really know how to achieve this? Maybe inkscape can create its own temporary directory which it removes after closing inkscape. Extensions could use this temporary directory.
Pim
On Mon, 2005-12-05 at 14:55 +0100, Pim Snel wrote:
I'd agree with Alan here. I think that ".svg.zip" would probably be better. This would probably assist in interoperability with other tools and will make users understand what they have better.
There is one advantage in giving it its own extension. The system can register this as mime type and automaticly open inkscape when it sees a *zink.
But I don't have any problems with the .svg.zip extension, so if you all agree I will change it to .svg.zip.
Can we register .svg.zip? Or is there no second period allowed for that? I'd agree that automatic opening would be better.
One thing that I'm curious about, is how we can clean up from the input extension. It sounds like it leaves the files in the temporary directory, which makes sense, but I'd like to be "good citizens" and clean up after ourselves. Does anyone have any ideas on this?
I don't really know how to achieve this? Maybe inkscape can create its own temporary directory which it removes after closing inkscape. Extensions could use this temporary directory.
Hmm, I'm not sure if this is a security risk. I think it would be okay as long as we randomly created the directory name on every run. Does that make sense to everyone else also?
--Ted
Ted Gould wrote:
One thing that I'm curious about, is how we can clean up from the input extension. It sounds like it leaves the files in the temporary directory, which makes sense, but I'd like to be "good citizens" and clean up after ourselves. Does anyone have any ideas on this?
I don't really know how to achieve this? Maybe inkscape can create its own temporary directory which it removes after closing inkscape. Extensions could use this temporary directory.
Hmm, I'm not sure if this is a security risk. I think it would be okay as long as we randomly created the directory name on every run. Does that make sense to everyone else also?
I don't know exactly what you're thinking of, but on Windows each user has his/her own temporary directory, so it shouldn't be much of a problem. Under Linux perhaps some kind of ~/.inkscape/temp directory could be used (not sure what the correct procedure would be under Linux).
Pim Snel wrote:
I'd agree with Alan here. I think that ".svg.zip" would probably be better. This would probably assist in interoperability with other tools and will make users understand what they have better.
There is one advantage in giving it its own extension. The system can register this as mime type and automaticly open inkscape when it sees a *zink.
But I don't have any problems with the .svg.zip extension, so if you all agree I will change it to .svg.zip.
As far as I can tell you can't register something like .svg.zip (I just tried on WinXP), and I wouldn't worry too much about interoperability. After all, Sun uses quite a few different extensions for jar-like files (jar, ear and war come to mind) as well (and so does OpenOffice).
And what about all the different formats that use XML, you don't give something an extension like .svg.xml or .xhtml.xml, just because it uses XML to serialize its data.
Quoting Jasper van de Gronde <th.v.d.gronde@...528...>:
As far as I can tell you can't register something like .svg.zip (I just tried on WinXP), and I wouldn't worry too much about interoperability. After all, Sun uses quite a few different extensions for jar-like files (jar, ear and war come to mind) as well (and so does OpenOffice).
And what about all the different formats that use XML, you don't give something an extension like .svg.xml or .xhtml.xml, just because it uses XML to serialize its data.
Agreed. Personally I would prefer .zink over .svg.zip.
-mental
--- mental@...3... wrote:
Quoting Jasper van de Gronde <th.v.d.gronde@...528...>:
As far as I can tell you can't register something like .svg.zip (I just tried on WinXP), and I wouldn't worry too much about interoperability. After all, Sun uses quite a few different extensions for jar-like files (jar, ear and war come to mind) as well (and so does OpenOffice).
And what about all the different formats that use XML, you don't give something an extension like .svg.xml or .xhtml.xml, just because it uses XML to serialize its data.
Agreed. Personally I would prefer .zink over .svg.zip.
-mental
I'm for the zink option too, double dotting things is a bad idea.
Sim
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Why not just add a preference setting to save the linked images and then just keep the same file extension (svg) (I believe that's what is done with OpenOffice with their default set as save images). It is so much easier if the file extensions are kept the same. Personally I always want to save any raster images with my inkscape file - the extra mb of storage is way more efficient that copying files and then not having the raster available or accidently deleting the raster which has happened to me several times already.
mental@...3... wrote:
Quoting Jasper van de Gronde <th.v.d.gronde@...528...>:
As far as I can tell you can't register something like .svg.zip (I just tried on WinXP), and I wouldn't worry too much about interoperability. After all, Sun uses quite a few different extensions for jar-like files (jar, ear and war come to mind) as well (and so does OpenOffice).
And what about all the different formats that use XML, you don't give something an extension like .svg.xml or .xhtml.xml, just because it uses XML to serialize its data.
Agreed. Personally I would prefer .zink over .svg.zip.
-mental
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id%16865&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Quoting John Taber <jtaber@...480...>:
Why not just add a preference setting to save the linked images and then just keep the same file extension (svg)
Because a ZIP file isn't valid SVG (even if it contains some).
However, there are ways to embed bitmap images in normal SVG (via data: URIs), and I believe we support that already (though I don't think we have UI for selecting this option yet). Note that using data: URIs means we've got to base64-encode the image data, so it's not really suited for very large images.
-mental
mental@...3... wrote:
Quoting John Taber <jtaber@...480...>:
Why not just add a preference setting to save the linked images and then just keep the same file extension (svg)
Because a ZIP file isn't valid SVG (even if it contains some).
I see your point, you are right - "zink" sounds good. Will be glad to have this new feature, thanks.
However, there are ways to embed bitmap images in normal SVG (via data: URIs), and I believe we support that already (though I don't think we have UI for selecting this option yet). Note that using data: URIs means we've got to base64-encode the image data, so it's not really suited for very large images.
-mental
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id%16865&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
However, there are ways to embed bitmap images in normal SVG (via data: URIs), and I believe we support that already (though I don't think we have UI for selecting this option yet). Note that using data: URIs means we've got to base64-encode the image data, so it's not really suited for very large images.
Also embedding images with base64-encode makes Inkscape very very slow. This was one of main the reasons why I started coding this extensions
Pim
On Thu, 8 Dec 2005, Jasper van de Gronde wrote:
Date: Thu, 08 Dec 2005 14:27:48 +0100 From: Jasper van de Gronde <th.v.d.gronde@...528...> To: inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Save and Open as .ZINK (was zip with images)
Pim Snel wrote:
I'd agree with Alan here. I think that ".svg.zip" would probably be better. This would probably assist in interoperability with other tools and will make users understand what they have better.
There is one advantage in giving it its own extension. The system can register this as mime type and automaticly open inkscape when it sees a *zink.
But I don't have any problems with the .svg.zip extension, so if you all agree I will change it to .svg.zip.
As far as I can tell you can't register something like .svg.zip (I just tried on WinXP), and I wouldn't worry too much about interoperability. After all, Sun uses quite a few different extensions for jar-like files (jar, ear and war come to mind) as well (and so does OpenOffice).
And what about all the different formats that use XML, you don't give something an extension like .svg.xml or .xhtml.xml, just because it uses XML to serialize its data.
Fair enough. You have clearly thought it through and there are good reasons to use a different extension. (Double extensions are inelegant but I only ever suggested using Zip or Jar. I was thinking primarily of inspecting the contensts of a collected file using programs like File Roller or Winzip and inspecting the contents of a Collected file but it isn't particularly important.)
The only minor concern would be that once you start offering Zink files there will be the expectation that future versions of Inkscape will be able to open them too but if you are careful that shouldn't be difficult.
Would it be possible to offer both, something like Type: "Inkscape Collected File (.zink, .zip) " including a secondary extension, so that if a user manually specified the file extension as .zip it wouldn't be replaced or changed?
Do whatever you think best, and thanks for your time and consideration on this.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Dec 8, 2005, at 12:00 PM, Alan Horkan wrote:
The only minor concern would be that once you start offering Zink files there will be the expectation that future versions of Inkscape will be able to open them too but if you are careful that shouldn't be difficult.
Would it be possible to offer both, something like Type: "Inkscape Collected File (.zink, .zip) " including a secondary extension, so that if a user manually specified the file extension as .zip it wouldn't be replaced or changed?
There is another option...
(just to complicate matters)
We might want to look at XML-binary Optimized Packaging (XOP), as mentioned in Inkscape RFE 119540.
Oooh... and Dr. Dobb's just ran an article on it too
XML-Binary Optimized Packaging XML and nontext data can work together http://www.sdmagazine.com/documents/s=9857/q=1/ddj0512g/0512g.html
On Mon, Dec 05, 2005 at 02:55:32PM +0100, Pim Snel wrote:
On Fri, 2005-12-02 at 01:07 +0100, Pim Snel wrote:
I enhanced the first extension, which was able to save a zip archive with svg and images, with an extra extension which is able to read the archive instantly. I changed the zip-extention to .zink which is of course a combination of Zip and Inkscape.
I'd agree with Alan here. I think that ".svg.zip" would probably be better. This would probably assist in interoperability with other tools and will make users understand what they have better.
There is one advantage in giving it its own extension. The system can register this as mime type and automaticly open inkscape when it sees a *zink.
But I don't have any problems with the .svg.zip extension, so if you all agree I will change it to .svg.zip.
I also think .zink would be fine. IIRC, the .jar format is also .zip underneath.
In fact... Were you aware of the 'inkjar' format that was implemented early on in Inkscape? I think it's akin to what you've done, although it wasn't very well documented. It might be wise to review that and if zink can do everything the inkjar format did, to deprecate inkjar and remove it from the codebase.
Also, please be sure to document and advertize this .zink format widely; I think part of the problem with inkjar was that its use didn't get documented so people didn't really use it, and ended up forgetting about it. It would be good for zink to take advantage of that lesson learned. ;-)
One thing that I'm curious about, is how we can clean up from the input extension. It sounds like it leaves the files in the temporary directory, which makes sense, but I'd like to be "good citizens" and clean up after ourselves. Does anyone have any ideas on this?
I don't really know how to achieve this? Maybe inkscape can create its own temporary directory which it removes after closing inkscape. Extensions could use this temporary directory.
Yes, I think most POSIX systems have a way to create temporary files and temporary directories that are automatically removed when the process exits. This is the typical (and most secure) way of handling it. The dir is named using the process id and usually placed in the system temp directory (e.g., on Linux /tmp or /var/tmp; on Windows C:\TEMP; etc.)
It would probably be worthwhile for you to look into how inkjar does it. I think inkjar doesn't actually need a temp dir; it just creates or reads the individual files directly into the archive. The code is in src/inkjar/. It's just one .cpp file.
Bryce
participants (9)
-
unknown＠example.com -
Alan Horkan -
Bryce Harrington -
Jasper van de Gronde -
John Cliff -
John Taber -
Jon A. Cruz -
Pim Snel -
Ted Gould