"Gather Resources" option for gathering fonts and images

Bug #386664 reported by Gatonegro
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Triaged
Wishlist
Unassigned
Nominated for 0.47.x by Jimmy Volatile

Bug Description

I have the fortune of working with a printing house that actually uses Inkscape (and Scribus and The GIMP) in they day-to-day. This means that they know the intrincacies of the program and I can send them pure SVGs with the reassurance they will know what they are doing.

One of the problems I find, though, is that whenever I prepare a complex design (a poster, or even the layout of a page for simple books) where several font faces and external images are involved it is a real pain to gather all the resources (font files, image files) that I need to send them.

Sure, Inkscape can embed images (but this generates huge SVG files and becomes aggravating when an image is used repeatedly in several files). It can also generate PDFs which I can send to them (but sometimes they need to do preprinting and there is no good PDF editor for GNU/Linux, and PDF doesn't support all the features SVG and Inkscape do).

Hence I think that an option that parses the SVG file and generates a tarball with the SVG, its associated images and the relevant font faces would be very nice to have.

Revision history for this message
Alexandre Prokoudine (alexandre-prokoudine) wrote :

I do remember that we had such an extension already

Revision history for this message
su_v (suv-lp) wrote :

svg_and_media_zip_output.inx:
  <_filetypename>Compressed Inkscape SVG with media (*.zip)</_filetypename>
  <_filetypetooltip>Inkscape's native file format compressed with Zip and including all media files</_filetypetooltip>

<http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/svg_and_media_zip_output.inx?revision=20240&view=markup>

svg_and_media_zip_output.py:
  An extention which collects all images to the documents directory and
  creates a zip archive containing all images and the document

  Copyright (C) 2005 Pim Snel, <email address hidden>
  Copyright (C) 2008 Aaron Spike, <email address hidden>
  this is the first Python script ever created
  its based on embedimage.py

<http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/svg_and_media_zip_output.py?revision=21154&view=markup>

Revision history for this message
Alexandre Prokoudine (alexandre-prokoudine) wrote :

Please test and let us know if it fits the bill

Revision history for this message
su_v (suv-lp) wrote :

With Inkscape 0.46+devel r21615 on OS X 10.5.7, fails complaining about a "file:///" URI "Could not locate file: file:///Users/suv/tmp/logo.gif", but the path is correct. Maybe a revers effect of the fix for bug#386069?

Revision history for this message
Alvin Penner (apenner) wrote :

yes, on Windows with rev 21612, I have the same problem :
Could not locate file: file:///C:/WINDOWS/Temp/spiro_smooth.PNG

Unfortunately, this doesn't work on 0.46 stable release either. On 0.46 stable I get a zip file output with no error messages, but when I try to open it, it says "not a valid archive"

Revision history for this message
su_v (suv-lp) wrote :

thanks for testing! I got a valid archive with r21615 (despite the error msg), inside
- a rewritten svg file (with an additional '.svg' ending added -> 'drawing.svg.svg')
  with a relative path in the '<image … xlink:href="logo.gif" … >' tag.
- no included 'logo.gif' media file.

Revision history for this message
Alvin Penner (apenner) wrote :

yes, there appear to be some problems here, beyond just the file reference issue. On Inkscape deveI, I got around the file reference problem by manually editing the .svg file to contain the relative link:

xlink:href="spiro_smooth.PNG"

this svg file opened properly and it created a .zip file with no errors. However, I cannot open the zip file : Winzip says "not a valid archive".

Revision history for this message
su_v (suv-lp) wrote :

there's a comment in the py source file about this kind of error: the zip file might be a plain svg file -> open with a texteditor to check?

Revision history for this message
Alvin Penner (apenner) wrote :

here is the complete zip file. Unfortunately, I'm on Windows so this may not be of much use to you. The text output of the zip is as follows:

PK♥♦¶ ₧╟:ë>╦ä♫▼ ♫▼ ► spiro_smooth.PNGëPNG

The file is 52 bytes long and it contains a reference to my image, but it does not actually contain the image.

Revision history for this message
su_v (suv-lp) wrote :

sorry, not enough coding skills on my part. I was hoping (naively?) the patch to 'embedimage.py' (bug #386069) which solved the mix of relative and absolute paths could be applied/transformed here, especially after I read the authors note in the src, that 'svg_and_media_zip_output.py' is based on 'embedimage.py'.

Revision history for this message
Alvin Penner (apenner) wrote :

yes, I believe there are two separate issues here, the first of which is the same as the embedimage.py problem

Revision history for this message
su_v (suv-lp) wrote :

I can't open the archive either (beyond as 'garbled text' in a texteditor).
Maybe this extension should be removed from the trunk/SVN? I wonder if there are other extensions that fail - unnoticed - but stay included in inkscape/share?

Revision history for this message
su_v (suv-lp) wrote :

I missed to properly test that yesterday: manually changing 'xlink:href' to a relative path (select image > context menu > image properties) before saving as 'compressed SVG with media' results in a zip archive that includes both the SVG and the referenced image file (minor bug: the '.svg' suffix is still appended twice to the included SVG file). Two (+1) issues remain:
- 'svg_and_media_zip_output' seems to be broken on windows (bug #246721).
- doesn't work with (absolute?) filename URIs (like embedimage.py, bug #386069)
- encoding: currently r/w paths in 'latin-1', isn't 'utf-8' common on all platforms now?
Manually editing all image properties before saving as zip archive isn't feasible except in test cases. I don't know enough about SVG standards and Inkscape inner workings - is this a bug in this extension or about changes in the SVG output of Inkscape (bug #386069, bug #168484, create URI names instead of local file names, how to use or keep relative path names in xlink:href)?

Revision history for this message
jazzynico (jazzynico) wrote :

The absolute path bug should now be fixed in rev 21656 (same patch as Bug #386069).
Tested on Ubuntu 9.04 only (I'll try on XP tomorrow), and everything looks fine except the double .svg suffix (workaround: save again as zipped file with media...)

Changed in inkscape:
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Alvin Penner (apenner) wrote :

    I just ran this new version on Windows XP. It looks good to me! I got the attached zip file with no error messages.
    Unfortunately, the zip file appears to be the same as the one I uploaded yesterday, it is empty. However, that is a separate issue. (So, is this empty zip file a Windows-specific problem?)
    Also the reference to latin-1 encoding appears to be hardcoded into the Python file, this could probably be made to be selectable, if desired.

Revision history for this message
su_v (suv-lp) wrote : Re: [Bug 386664] Re: "Gather Resources" option for gathering fonts and images

thanks JazzyNico for your quick response! On Inkscape r21615, Mac OS X 10.5.7:
- valid archive: ok
- rel/abs path: ok
- included media files: ok
- xlink:href in created/resaved file: ok
- encoding: test handling of german umlauts in linked image filename? fail

inkscape displays the linked images with special characters in their
filenames correct. python extension fails when trying to resolve filename?

filename: 'upper-left-äöü.png' (pasted name from osx clipboard - I had
renamed 'upper-left.png' in the filemanager (Finder), where it displays as
'upper-left-äöü.png').

I don't know what encoding OS X uses with the clipboard, my default language
in OS X is set to 'en_US', the keyboard layout is 'de_CH'. The filename also
displays correct in the Terminal.app with bash, LANG='en_US.UTF8' and in the
X11/GTKfilechooser dialog of Inkscape (started from a shell with LANG="en_US").

extension error message:

Traceback (most recent call last):
  File "/Users/suv/.config/inkscape/extensions/svg_and_media_zip_output.py", line 122, in <module>
    e.affect()
  File "/Users/suv/Applications/Inkscape-21615.app/Contents/Resources/extensions/inkex.py", line 198, in affect
    self.effect()
  File "/Users/suv/.config/inkscape/extensions/svg_and_media_zip_output.py", line 80, in effect
    self.collectAndZipImages(node, docname, z)
  File "/Users/suv/.config/inkscape/extensions/svg_and_media_zip_output.py", line 107, in collectAndZipImages
    z.write(absref.encode("latin-1"),os.path.basename(absref).encode("latin-1"))
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/zipfile.py", line 541, in write
    st = os.stat(filename)
OSError: [Errno 2] No such file or directory: '/Volumes/blue/src/Inkscape/dev/launchpad/media_zip_output/img-de/upper-left-\xe4\xf6\xfc.png'

result: empty zip archive

Revision history for this message
jazzynico (jazzynico) wrote :

I think the empty zip file is due to the fact that it is first created in a temporary directory, and then copied to the final location using sys.stdout:

        out = open(self.zip_file,'r')
        sys.stdout.write(out.read())
        out.close()

The temporary zipped file works well, but after opening it and writing it to stdout, it fails on Windows XP.

Attached is the latest file version, not tested on Linux (I'll try later today) and Mac.
Recent changes are: double .svg suffix fix, latin_1 replaced by utf-8, and temporary directory not removed (for testing purpose).

Revision history for this message
su_v (suv-lp) wrote :

On 23/6/09 14:36, JazzyNico wrote:
> Attached is the latest file version, not tested on Linux (I'll try
> later today) and Mac. Recent changes are: double .svg suffix fix,
> latin_1 replaced by utf-8, and temporary directory not removed (for
> testing purpose).

utf-8, doubled suffix are fixed. But the latest version no longer saves
any relative pathnames in xlink:hrefs which to me defeats the
portability purpose of the archive...? See attached attempt to compare
the output. Rev 21656 created self-contained archives with no
absolute/outside links.

Do you get the same results?

Revision history for this message
jazzynico (jazzynico) wrote :

Relative pathnames fixed. Tested on Ubuntu and committed rev. 21669.
Well, now we have the remaining Windows empty zip file...

Since this report is mainly a wishlist, I suggest we open a new bug one for the remaining bug, and leave this one as a wishlist (fonts in the zip file).

Revision history for this message
jazzynico (jazzynico) wrote :

Back to wishlist... (remaining bug now in Bug #391307)

Exporting the SVG with imported images is already available with File>Save As>Compressed Inkscape SVG with media.
It would be nice to add the relevant font faces in the same zip file.

Changed in inkscape:
importance: Medium → Wishlist
status: In Progress → Confirmed
Revision history for this message
su_v (suv-lp) wrote :

On 23/6/09 21:58, JazzyNico wrote:
> Relative pathnames fixed. Tested on Ubuntu and committed rev. 21669.

Fix confirmed on OS X 10.5.7 with Inkscape r21615 and
svg_and_media_zip_output.py r21669: my 3 testcases (abs, rel, utf-8)
all export fine. The archives include all images and are
'selfcontained', encoding ok.

Thank you for your quick and thorough work!

tags: removed: images resources
su_v (suv-lp)
tags: added: exporting saving
Revision history for this message
Guillermo Espertino (Gez) (gespertino-gmail) wrote :

It works fine, but it would be nicer if the images were saved in a folder, so you have the svg and a folder containing the images inside the compressed file.
The fonts part would be nice too, but maybe it will be difficult to retrieve, since different operating systems manage their fonts in different ways. But at least it would be nice to have the fonts properly collected for installing them later using a font managment software.

Revision history for this message
jazzynico (jazzynico) wrote :

Gez> it would be nicer if the images were saved in a folder.

We could add it as an option (and let users set the folder name).

Gez> But at least it would be nice to have the fonts properly collected for installing them later using a font managment software.

Listing all the fonts of a document should not be too hard. We could then provide an optional list in the compressed file.

Adding you ideas to my todo list.

Revision history for this message
Gatonegro (gatonegro) wrote : Re: [Bug 386664] Re: "Gather Resources" option for gathering fonts and images

--
Denís Fernández Cabrera
Gatonegro deseño
http://gatonegro.me

2010/11/22 JazzyNico <email address hidden>:
> Listing all the fonts of a document should not be too hard. We could
> then provide an optional list in the compressed file.

A list of the fonts used in the document would be nice. It would be
nicer if it listed the font filenames and installation paths in the
system (for easy retrieval, to be able to copy them before sending
them to a client). And it would be nicest if the program actually did
the font-gathering itself, creating a folder with a copy of the TTF or
OTF files required by the document.

That said, I'm happy to see this idea is advancing -- keep up the good work!

Revision history for this message
jazzynico (jazzynico) wrote :

Some improvements can be tested in the trunk, revision 10022.
It's now possible to set a specific image directory in the zip file and to add the list (text file) of all the fonts used in the SVG document.
Unfortunately, adding the fonts directly to the zip is a bit more difficult and OS dependent, and thus not implemented yet.
Comments are welcome!

Changed in inkscape:
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.