Issue 50096 - Linking embedded objects by default causes problems on document copy/move
Summary: Linking embedded objects by default causes problems on document copy/move
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0 Beta
Hardware: All All
: P3 Trivial with 6 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2005-05-31 08:05 UTC by luke_hutchison
Modified: 2014-03-03 11:32 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description luke_hutchison 2005-05-31 08:05:26 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:

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.
Comment 1 luke_hutchison 2005-05-31 08:16:47 UTC
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.

Comment 2 wolframgarten 2005-05-31 09:24:04 UTC
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.
Comment 3 wolframgarten 2005-05-31 09:24:45 UTC
Reassigned. Is this impress' fault or the sources fault?
Comment 4 clippka 2005-05-31 09:40:52 UTC
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.
Comment 5 wolframgarten 2005-05-31 10:05:17 UTC
Ok, like I expected. The problem lies within nautilus and not impress.
Comment 6 wolframgarten 2005-05-31 10:05:33 UTC
Closed. Thanks for your help.
Comment 7 luke_hutchison 2005-05-31 17:33:39 UTC
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.

Comment 8 luke_hutchison 2005-05-31 17:34:50 UTC
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.
Comment 9 wolframgarten 2005-06-01 09:45:28 UTC
Ok, thanks for that. I had a second look at this regarding our different
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. 
Comment 10 kozmoz 2010-10-16 13:08:46 UTC
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

See also this forum discussion:

Edit>Links>Break link is not a solution. It isn't even clear that the image is
linked instead of embedded. 
Comment 11 kozmoz 2010-10-16 14:17:21 UTC
BTW, apparently this is fixed in LibreOffice 3.3.0 Beta 2.
Comment 12 dudson 2014-03-03 11:32:58 UTC
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.