Image properties dialog enhancements

Image properties dialog enhancements

Current Status

This blueprint is no more in a blueprint state.

Work has been done by students from Ecole Centrale Lyon. You can read their report File:Centrale Lyon 2010.pdf. Contact User:Steren for more information.

The code is currently in a branch. The main features were added, but finishing, testing, reviewing and polishing are needed to merge it into trunk.

The current 0.48 version uses file:// before the path in xlink:href attributes and the path is ASCII encoded. Imagelink uses the path directly (relative and absolute path) and keeps all non-ASCII characters non encoded. See http://www.w3.org/TR/xlink/#link-locators (--JazzyNico 07:31, 11 July 2010 (UTC))

Relative links

scenario:

• 1 - Save your document, drop an image from a subdirectory on the canvas, select "link", see that the link should now be relative.
• 2 - do not save the document, import an image on the canvas, the link is absolute, save the document near the image, the image link should be updated with a relative link.

status: test in progress

On Ubuntu (--JazzyNico 07:16, 11 July 2010 (UTC)):

• 1. Tested successfully with images in the same path or in a subpath of the saved document, with ASCII and non-ASCII characters (doesn't work if the image is in a different path or a higher on the path).
• 2. Tested successfully with images higher or lower in the same path, or in a different path.

bugs:

Scenario 2 doesn't work after moving the document (--JazzyNico 07:22, 11 July 2010 (UTC))

• 1. Create a document with scenario 1. The image link is relative.
• 2. Save the document in an other path. The link is now absolute, and the image gets a new sodipodi:absref attribute.
• 3. Save the document to its original place. The link is still absolute (and sodipodi:absref is still present).
• Workaround: remove the sodipodi:absref with the xml editor and the link is relative again.

Relink tool

status: features are here, need to polish the UI

scenario: create a document with linked images, save this svg. Move the svg to another folder. reopen it, the relinking tool appears and help you relink the broken images.

TODO:

• do not show an alert dialog when relinking is finished, prefer the status bar ?

bugs:

• when opening a file with a broken link, the alert dialog doesn't show well the names of missing files.
• (--JazzyNico 18:14, 11 July 2010 (UTC)) on Ubuntu 10.04, libgtk 2.20.1-0ubuntu2, inkscape crashes when opening the moved file with the following error:

Program received signal SIGSEGV, Segmentation fault.

0x00778f63 in IA__gtk_label_new (str=0x1 <Address 0x1 out of bounds>) at /build/buildd/gtk+2.0-2.20.1/gtk/gtklabel.c:1397

1397 /build/buildd/gtk+2.0-2.20.1/gtk/gtklabel.c: Aucun fichier ou dossier de ce type.

in /build/buildd/gtk+2.0-2.20.1/gtk/gtklabel.c

Image propriety window

scenario : right click on an image of the canvas, select image properties. A new window should allow you to see the image thumbnail and infos, choose another image, embed the image, reset ratio.

status: code started, not finished

TODO: (refering to the mockup on this page)

• thumbnail
• ...

Summary

Organizing linked bitmap images is quite a hassle at the moment. When a bitmap file is renamed or moved to a different location, the corresponding bitmap links need to be changed manually one by one in Inkscape, involving a tedious copy and paste process for the filenames. This can be improved. This is an alternative to the method proposed in the article Linked bitmap manager.

Proposal

The proposal is to add some minor enhancements to the existing image properties dialog, in order to improve its usability and solve broken links in an easy and automated way.

The first thing that has to be solved is the inconsistency in absolute/relative linking. At the moment all the images are linked with absolute paths, and that can be very inconvenient when working on the same file over a network. The images in the same directory than the SVG file should be linked with relative paths, and so the images in children directories. This condition can be extended to folders contained by the same parent folder that contains the SVG.

That would solve common problems like broken links if the file was created or is retrieved from a remote machine over a samba mount in linux, for instance.

Another common situation where absolute links are useless is a project retrieved from a backup. Again, all files have to be re-linked. So in the first place, fixing the absolute/relative linking will solve a lot of broken links.

However, that wouldn't fix all the broken links, and there are several situations where moving or renaming a linked file will result in a broken link, so another strategy should be prepared for that.

As it would discussed in the mailing list and related bug reports, the lack of a browse button in the image properties dialog makes it too tedious to re-link missing images, so adding that button would make things easier.

But having dozens of broken links would be still a hassle even having that button, so a "smart re-linking" strategy would be handy.

Adding a modal warning about broken links would be excessive since we already have a pretty visible way to display that there are missing bitmaps, so the focus should be put on providing an automated way to resolve broken links using a single manual replacement. As it was expressed earlier, a proper management of absolute and relative links would help with this task.

Image Properties Dialog Re-design

One of the most annoying things about the Image Properties dialog is that one window is opened for each image. That window should be re-utilized and be dockable. When the user selects another image, its information should fill the same properties window, not a new one. This dialog should be also accessible from the Object menu (like the object properties dialog), not only from the context menu of a selected image.

At the top there's an area that shows general information about the image, along with a thumbnail. This will give a glimpse about the image we're working on.

The URL field willbe accompained by a browse button for easy image re-linking. The URL text can be rendered red if the link is broken, giving a visual hint to the user that the path isn't correct.

I added radio buttons for selecting if the image is linked or embedded, since that is part of the image properties and it would make sense to put it in that dialog instead of a separate extension.

The fields for the dimensions of the image were preserved, adding a units selector and a proportional transformation lock.

The position fields were removed, since they are not (from the user point of view) part of the image properties, but an attribute of the object on the document. It isn't likely that a user will set the position of the image object on the document from a window that covers it, He will probably use the tool controls bar selectors instead.

An "advanced options" area was added. It lets the user enter the object ID, change the resolution of the image and use the original image's aspect ratio.

Comment: What about adding a checkbox in the section image source, just below the edit control URL named Relative and to display the (on-the-fly-calculated) commun URL prefix (between the linked image and the Inkscape file) in a grey font? Best regards --Uncopy 10:52, 27 October 2009 (UTC)

Comment: The radio buttons should be for absolute/relative, and for embedded/linked there should be a push button that says "embed" or "extract..." based on the state of the image. Embedded/linked cannot be a radio button, because switching to "linked" needs to bring up a file browser. Doing so in response to radio button change breaks all the interface guidelines I know. --Tweenk 19:31, 5 March 2010 (UTC)

Comment: I'm ok with adding the relative/absolute switch. My original proposal was to do it kind of automatically, but I can see that it can be really problematic.

Regarding the Embedded/linked thing, the original proposal considers "linked" as the default importing strategy. This has been changed recently in inkscape but I think it's plain wrong. Embedding always and then extracting contributes to having duplicates of the original images everywhere. I think that embedding should be the default for the "make bitmap copy" command, and in that case the extract command should make sense. The original proposal doesn't go against that practice either: if the image is already embedded, the file browser is hidden. If you click on the "linked" radio button, then the extract dialog would pop up. We must, however, find a way to make all the situations co-exist nicely: linked to embeded / embedded to linked (extracted) / Re-link linked image / Re-link embedded image. --Gez 19:31, 3 May 2010 (UTC)

Smart image re-linking

If there are several images with broken links and we choose the right path for one of those images (and they share the same location) Inkscape should compare the common location of the broken links and fix the remaining images with the new location automatically.

Example: there are 3 images with broken absolute links:

1. /media/disk/inkscape-works/images/cat.png
2. /media/disk/inkscape-works/images/dog.png
3. /media/disk/inkscape-works/images/bird.png

when the user sets a relative link for the first image to images/cat.png the other images should be automatically relinked, since they had:

• broken links
• the same orignal path
• they exist in the new location.

This operation could be silent, but when there are several images the re-linking process can take some time, so a confirmation window would provide a clear warning about the operation is going to be performed, with the possibility of choosing "yes" to perform the re-link process with the images found, or skipping it choosing "no" This window would appear right after a single re-link.

The confirmation window can optionally show details about the images that are going to be re-linked, with the ability to untick the items that the user doesn't want to automatically re-link.

Comment: It is possible to uncheck all images and then click "yes", which doesn't make much sense. The text should be worded in a different way. For example, the prompt could be something like "Additional missing images were found. Select the image links you want to fix", choices would be "ok" and "cancel", and the list would always be visible. --Tweenk 19:24, 5 March 2010 (UTC)

Manual selection of relative or absolute paths

Steren pointed me out that there are some situations where selecting manually if the image will be linked using an absolute or a relative path. In that case, the file selector window that opens with the "browse" button of the Image Properties dialog could have radio buttons for selecting absolute or relative. The default value would be proposed by inkscape according the guidelines discussed earlier, but the user would have the ability to force the path to be relative or absolute, according his needs. However, that feature imposes a potential problem: How the smart re-linking feature should act in that case? The automatically re-linked images would use the same path type than the manually selected?

Linked vs. Embedded

The new image properties dialog would have radio buttons for choosing if the image is linked or embedded.

The behavior of those buttons would be the following:

• If the image is linked (default for the imported bitmaps) the behavior would be the described earlier in this blueprint
• if the user chooses "embedded", the url input and its browse button will be grayed out, and the image will be embedded into the SVG document
• if the user chooses "linked" on an image that was previously embedded, a file dialog will be opened, prompting the user to enter a location and a file name (by default the id and the path of the SVG file will be used) to extract and save the image.
• if the link is broken, the "embedded" option will be grayed out until a valid path is set.

Comment: Embedded / Linked cannot be a radio button, because when we open a file with an embedded image, it has no path assigned. The button should say "extract..." when the image is embedded and bring up a file browser that allows the user to choose the location, and it should say "embed" when the image is linked. There should be a different radio button though: one that allows the user to choose between an absolute and a relative link. --Tweenk 19:29, 5 March 2010 (UTC)

Image Resolution

At the moment inkscape doesn't use the imported image's resolution value and use 90 dpi instead. There is a whishlist item in Launchpad about that and it should be fixed in order to implement this feature, otherwise the resolution value wouldn't make sense in this dialog. Notice that resolution value would change the "real world units" size of the image in the document, so changing that value would have impact in the dimensions selectors if they're set to real world units. The original file's resolution is important because it would tell inkscape what dimensions use for the imported image on the document. In my oppinion, if the default document's units are real world units, the resolution value should be used; if pixels are used as default units, the resolution should be disregarded, and grayed out in the dialog.

General Benefits of this change

These enhancements would tackle several usability issues in the current image properties dialog and provide an easy and straightforward solution for broken image links. The image properties would be unified in a single window, adding features that are currently available only via extensions, in locations that may not be so obvious for the new users.

TODO

There are a couple of interesting suggestions that can be added to this dialog but I hadn't the time to develop:

• The thumbnail could be used for external editing (double clicking on it, or using a button)
• Add a new option for embedded images: re-link to the original file.