Add an option to the preferences-dialog: "Auto embed images"

Bug #171842 reported by Bug Importer on 2007-03-31
This bug affects 9 people
Affects Status Importance Assigned to Milestone

Bug Description

There should be an option that says "auto embed images" so that the user
does not always have to select "Effects -> Pictures -> Embed all pictures"
after inserting an image (or more).
Thanks a lot!

nightrow (jb-benoit) on 2007-12-20
Changed in inkscape:
importance: Undecided → Wishlist
Ace2016 (ace2016) wrote :

I would also like this

Ryan Lerch (ryanlerch) on 2008-01-14
Changed in inkscape:
status: New → Triaged
Rygle (rygle) wrote :

I think this option is extremely important! There should be an option in the Inkscape preferences that allows this.

There should also be an automatic warning when saving files with non-embedded images, which you can turn off. This would be similar to the way that Gimp's Tip Of The Day feature works - if you don't want it again, you just tick a box and it's gone. It's silly that you have to find this out by sending a file to someone and finding out that they got it all botched up.

Please! Please! Please!

Rygle (rygle) wrote :

Please see the amount of discussion on this bug here;

IMO the option switcher should be placed in the save dialog (a checkbox). So everytime a file is svaed as SVG, the user can choose to embed the bitmaps.
Another great thing would be to add an "embed this image" option in the contect (right click) menu when clicking on a placed bitmap. This way the user can choose to embed only particular bitmaps.

That would be a nice step ahead toward better usability.

jharker (harker) wrote :

I agree with all of the above. In my opinion this is a significant UI and usability issue of medium priority. I often create SVG files containing images from several directories, then move the SVG or image files elsewhere and end up with most of the images missing. It's incredibly frustrating. I'm glad to know there's a way to embed images, but this should really be the default behavior. At the very least, there should be:

1. An option in the preferences menu (or elsewhere) toggling auto-embedding of images. Preferably this should default to "yes".

Ideally, there should also be:

2. A window allowing the user to view a listing of images used in the SVG file. The listing should let users view and edit, for each image:
 a. The path of the image source file;
 b. Whether the source file path is relative or absolute;
 c. Whether a copy of the image should be embedded with the SVG file;
 d. A button to trigger an auto-update of the embedded image from the source file.

I think the current behavior is unexpected, and hence becomes a stumbling/frustration point for new users.

Thanks for you attention!

Jon A. Cruz (jon-joncruz) wrote :

I'm pretty sure that embedding is not ideal solution, as it breaks other usages. And if an "auto-embed" option is added, I'm very, very, very sure it should not be true by default.

However, avoiding the surprise and breakage is very good. It's just the "how" to best avoid the problems that needs to be worked out. (we want to avoid frustrating half of the users to make the other half happy. Something that solves it for everyone is ideal)

Gatonegro (gatonegro) wrote :

There is now an option to save the SVG file as a ZIP with the relevant images... perhaps that fixes this?

BrendaEM (brendieellen) wrote :

The image linking needs work. Currently, moving a folder from computer to computer or renaming the parent folder breaks the image linking. Currently no linked images can be transferred from computer to computer because the absolute path is saved internally.

When the user embeds and image, which is in the same folder as the parent--only the filename should be embedded--not the folder hierarchy.

Please fix this.

[Lastly, the instructions on embedding images are broken for modern Inkscape; I cannot find how to embed and image.]

In the default install on Mac OS X with 0.47, the (Effects -> Pictures -> Embed all pictures) does not work:

"The fantastic lxml wrapper for libxml2 is required by and therefore this extension. Please download and install the latest version from, or install it through your package manager by a command like: sudo apt-get install python-lxml"

I recommend the importance of 171842 be upgraded to a bug.

jazzynico (jazzynico) on 2010-05-22
tags: added: preferences
removed: ui-preferences
jazzynico (jazzynico) on 2010-08-24
Changed in inkscape:
assignee: nobody → JazzyNico (jazzynico)
milestone: none → 0.49
sdaau (sd-imi) wrote :

Hi all,

For what is worth, my 2c:

As there is already "embed all" command, I'm either for

> to add an "embed this image" option in the context (right click) menu

or also add a checkbox on the File Import dialogue, that shows up if the category is Images, allowing for choice of embed or not... Or both options :) Option for changing the default behavior might be OK, but should be off by default ...


sdaau (sd-imi) wrote :

Ups, wish I could edit my post - just realized if you drag and drop png file from Nautilus to Inkscape, Inkscape will ask - embed or link :) (Inkscape 0.48, Ubuntu Lucid)

Qianqian Fang (fangq) wrote :

I strongly support embedding bitmaps by default in Inkscape (regardless that this CAN be done in the current version). Especially when copy/paste bitmaps from clipboard, there is no reason you expect people to keep track of the random files dumped at their home directory: it looks ugly, mixed with many pasted-but-then-deleted resources and makes it very difficult for data backup/management.

The idea of linking resources in HTML/XML is to expect the resources to be reused at some point, thus, a moderate sacrifice of the portability is acceptable. This is hardly the case for drawings and non-logical content. To make linking the default behavior, IMHO, is a bad choice for this specific application (imagine that if powerpoint or OOo drawing use links by default for copy/paste/import, I will be really mad).

Please reconsider this from a usability perspective.

Krzysztof Kosinski (tweenk) wrote :

The current state of this issue:
- Pasting a bitmap (e.g. copied from Firefox or Gimp) always embeds.
- Pasting, importing or DnDing a bitmap file asks whether to embed.
- Linked images can be embedded using extensions.

Remaining items:
- Add context menu item to embed / extract image

jazzynico (jazzynico) wrote :

I'm working on adding a new preference that will allow users to (when pasting, importing or DnDing a bitmap) : always embed, always link (no dialog), or ask (current behavior).
Context menu additions also in progress.

Changed in inkscape:
status: Triaged → In Progress
jazzynico (jazzynico) wrote :

Partial patch attached. Adds the new preference.
Context menu still to be done.

jazzynico (jazzynico) wrote :

Related reports:
Bug #635373 "Opening PNG in Inkscape shows nonsense "png GDK pixbuf Input" alert".
Bug #555234 "[bitmap import] modal dialog destroys workflow".

jazzynico (jazzynico) wrote :

Correction (comment #14): the patch will NOT affect pasting. Current issues with external pasting are due to Bug #847374 "trunk no longer always embeds when pasting bitmap from clipboard".

jazzynico (jazzynico) wrote :

New version of the patch.

The context menus call the embed and extract python extensions, with their default values. I'd modify it a bit so that the embed entry don't show the extension dialog and limit its scope to the selection.

After changing it many times, I've finally kept the file type in the title because if the Always embed and Always link options apply to all file types, Ask uses a different default value.

The extension dialog now shows a Don't ask again checkbox so that users access the preference value directly, without having to browse the Inkscape Preferences dialog. Known (minor) bug, the Prefs dialog is not updated (except if you restart inkscape) when the checkbox is used (under investigations).

I've tried to replace the extension description with tooltips, but the radiobutton widget doesn't implement (or it doesn't work) the feature. Works well with the checkbox.

The patch also fixes Bug #847374 "trunk no longer always embeds when pasting bitmap from clipboard".

As you can see, there are still things to improve, but nothing critical. Don't hesitate to test and comment!

jazzynico (jazzynico) wrote :

Feature committed in the trunk, revision 11097.
In the context menu, the embed command applies to the selection, with no extra dialog.

Changed in inkscape:
status: In Progress → Fix Committed
su_v (suv-lp) wrote :

The newly added helper extension to embed selected images only (without options) gets added to the top-level 'Extensions' menu - could it be moved into the 'Images' sub-menu? (AFAIU Inkscape has no option or extension parameter to hide the menu entry for 'effect' extensions).

I did try to alternatively work with the verb 'org.ekips.filter.embedimage.noprefs' instead of calling the new extension (in 'src/ui/context-menu.cpp'), after changing the default action to 'selected images only' for the existing extension, but apparently this does not work as originally described (or I misunderstood):
«(…) all preset filters and extensions have two verbs each: One is the same as running this filter or extension from the menu (which may or may not display a dialog with parameters); the other, with .noprefs appended, always runs without a dialog, using default values.» (quoted from 'The Book of Inkscape').

Calling the existing (modified) extension with '.noprefs' appended apparently still uses the settings stored in the prefs file (last used setting whether to apply to all or only selected images), and not "default values" (which I had assumed would be those hard-coded as default values in the INX file and python script). The only difference appears to be the suppression of the dialog (i.e. same as menu 'Extensions > Previous Extension').

jazzynico (jazzynico) wrote :

> The newly added helper extension to embed selected images only (without options) gets added to the top-level 'Extensions' menu - could it be moved into the 'Images' sub-menu?

Oh. I was so sure removing all the menu stuff in the inx file would hide the extension that I didn't even checked it...

> I did try to alternatively work with the verb 'org.ekips.filter.embedimage.noprefs' instead of calling the new extension (in 'src/ui/context-menu.cpp')

Yes, I first tried the verb way too, but didn't managed to make it work as expected.

I'll try to see if it's possible to remove the extension from the menu or fix the noprefs system so that it really uses a default value, and not the stored one.

Changed in inkscape:
status: Fix Committed → In Progress
jazzynico (jazzynico) wrote :

<effects-menu hidden="true" /> is our friend...

jazzynico (jazzynico) wrote :

Extension removed from the menu as of revision 11101.

Changed in inkscape:
status: In Progress → Fix Committed
su_v (suv-lp) wrote :

Another questions: since the effect extensions (as well as input/output extensions) usually only get added to the UI (menu, file type list) if properly loaded - could you add a check for it in the context menu and only activate the entries if the extensions are found and loaded?

Currently, if I remove the INX file, embedding the selected image silently fails (with regard to the GUI), only with this message on the console:

 Unable to find: org.ekips.filter.embedselectedimages

Since there have been new requests filed to add extensions to other places (hard-coded in the GUI at compile time as buttons on controls bars and in (context-)menus), and script extensions are external files which could be missing for whatever reason, it might be worth the additional check, and setting the GUI element inactive if the extension (or verb) is missing.

jazzynico (jazzynico) wrote :

Yes, it would indeed be safer to test the existence of the extension.

jazzynico (jazzynico) wrote :

Extensions properly checked as of revision 11106.

jazzynico (jazzynico) on 2015-02-14
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.

Duplicates of this bug

Other bug subscribers