Apache OpenOffice (AOO) Bugzilla – Issue 50096
Linking embedded objects by default causes problems on document copy/move
Last modified: 2014-03-03 11:32:58 UTC
By default, images *are* embedded as links in Impress if they are drag-dropped from Nautilus, but they are *not* embedded if the user uses "Insert->Picture". They are also *not* linked in Writer in either situation. The default of embedding images as links is very problematic. I have personally had moments of panic on two occasions as I turned up somewhere to give a presentation and found that the presentation was broken because I had transported a presentation without its linked images (and I didn't know the images were linked). What motivated me to file this issue report was the following from Herbert Figuiere: http://www.figuiere.net/hub/blog/?2005/05/29/197-ooo-impress I believe the default for all OOo apps should be to *not* embed images (or any other embedded object) if they are either "Insert"ed or drag-dropped. Links should be explicitly created if necessary. This could be accomplished by remembering the path to every original object in a document, and reversing the behavior of the "Links" dialog to *make* a link to a resource, rather than *break* a link to a resource. The current behavior of linking by default on drag-drop to Impress (but not to Writer, and not upon Insert) is inconsistent, and can cause potentially bad problems as I attested above. Things are pariticularly bad for presentation files, since they are frequently moved to other machines for display, and the link is even preserved upon export to .PPT.
Sorry, the terminology I used in the first paragraph was confusing, since I used "embedded" to mean "embedded as links". Here it is again: By default, images *are* linked in Impress if they are drag-dropped from Nautilus, but they are *not* linked if the user uses "Insert->Picture", they are instead embedded directly in the document. They are also *not* linked in Writer in either situation, they are always embedded.
I had a test on this. Under Windows: Explorer -> Impress: linked bitmap IE-> Impress : doesn't work Mozilla -> Impress : bitmap is embedded Firefox -> Impress : bitmap is embedded Linux Gnome: Nautilus -> Impress: linked bitmap Mozilla -> Impress : hanging system, process must be killed Linux KDE: Konqueror -> Impress:linked bitmap Mozilla -> Impress : HTML tag is inserted as text For me it seems a this is maybe a problem of the source application and not a problem from impress... passing this over to development.
Reassigned. Is this impress' fault or the sources fault?
This is not fixable as Nautilus does not put an image into the clipboard but a mere link itself. From our application whe can't figure out if this is just a link or was a graphic before drag'n'drop. Therefore we can't change our behaviour there.
Ok, like I expected. The problem lies within nautilus and not impress.
Closed. Thanks for your help.
Whoa, hold on a second -- cl said "This is not fixable as Nautilus does not put an image into the clipboard but a mere link itself." I don't believe that is true, because Writer parses the link, finds the image and embeds it. Just because you get a link rather than an image does not mean you have to embed the image as a link. The whole fact you can display a linked image means you can fetch it and embed it. Also, wg wrote "Mozilla -> Impress : hanging system, process must be killed." Doesn't that qualify for further investigation too? wg, are you going to create another issue for that? If so, please put the bug number here. I would like to re-open this because I believe it *can* be fixed, and the current behavior presents a real usability problem. If you haven't done so, please read Hubert Figuiere's description on the link I provided -- he said it was the "first time and the last time" he'd use Impress, because he thought it was broken. I thought the same thing, but persisted until I figured out that links were being embedded. It took me a while to figure out that the behavior was different for drag->drop and Insert. Again, my original suggestion was to embed everything, but to remember the path to the original object, so that "break links" becomes "make links". Just because Nautilus gives you a file:/// URI doesn't mean everything that is drag->dropped can't be embedded. Thanks!
Sorry, to clarify my first point in the above comment -- the fact that Writer handles drag-drop from Nautilus fine means that it is possible in Impress.
Ok, thanks for that. I had a second look at this regarding our different applications: Nautilus-> drag and drop to ->Writer -> embedded bitmap Nautilus-> drag and drop to ->Calc -> text containing path Nautilus-> drag and drop to ->Impress -> linked bitmap Nautilus-> drag and drop to ->Draw -> linked bitmap I think we should have a consistent behaviour here. Reassinging to UserEx, please decide what to do.
I think this a serious usability issue. Drag and dropping an image, the user expects the image to be in the document. It is just weird and pretty annoying to discover afterward that the images are not there when the presentation is opened at another computer. It just doesn't make sense. See also this forum discussion: http://user.services.openoffice.org/en/forum/viewtopic.php?f=10&t=14972 Edit>Links>Break link is not a solution. It isn't even clear that the image is linked instead of embedded.
BTW, apparently this is fixed in LibreOffice 3.3.0 Beta 2.
Agreed with that images should be embedded by default. Avanced users could always do copy as and have options there do embedding. And the original linked location should be available in the meta information of the embedded image.