Sounds like a user error. Of course you can overlap pictures, it's a feature, not a bug.

@Nicolas Mailhot
Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? 
Please:
- Write a meaningful Summary describing exactly what the problem is
- Attach a sample document (not only screenshot) or refer to an existing 
  sample document in an other Bug with a link; to attach a file to this 
  bug report, just click on "Add an attachment" right on this page.
- Attach screenshots with comments if you believe that that might explain the 
  problem better than a text comment. Best way is to insert your screenshots
  into a DRAW document and to add comments that explain what you want to show
  (attachment 68877 [details], attachment 68490 [details])
- Contribute a document related step by step instruction containing every 
  key press and every mouse click how to reproduce your problem 
  (similar to example in Bug 43431)
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
  -- what EXACTLY is unexpected
  -- and WHY do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your PC (video card, ...)
  –- Libo settings that might be related to your problems 
  -- everything else crossing your mind after you read linked texts

writer should not overlap images by default especially when they format asks to clear everything around them. Clear means "leave my image alone"

This is especially annoying when the inserted images make most of a page surface (big images, scanned images, whatever)

I am adding an update to this bug that provides an example of the problem. If the Graphics frame style has been defined with:

- Anchor "To paragraph"[1]
- Wrap "None"

Then, regardless of the graphic size, Writer should attempt to prevent image overlap. 

Steps to reproduce (using LO v4.1.2.2 under Ubuntu 10.04):
1. Download and save the AskLO site logo: http://ask.libreoffice.org/m/tdf/media/images/tdf-logo.png
2. Open Writer.
3. Insert the AskLO logo into the document (Insert > Picture > From File...). By default, the graphic is inserted with Anchor "To paragraph" and Wrap "Optimal Page Wrap".
4. Right-click on the image > Picture... > Wrap tab > under Settings select "None". Click OK.
5. In the Styles and Formatting panel pull down the "New Style from Selection" button at top-right and select "Update Style".
6. De-select the graphic (click on the carriage return that is now after the inserted graphic).
7. Insert a second copy of the AskLO logo into the document (Insert > Picture > From File...). 

Observed behaviour:
Second logo directly overlaps the first instance, even though right-click now shows it is using Anchor "To paragraph" and Wrap "None".

Expected behaviour:
I think most users would expect the second instance of the graphic to observe the Wrap "None" setting and be placed beneath the first graphic.

[1] It is currently not possible to set anchoring for a frame style, by editing the style. This is described in bug #32484, which this bug may depend on.

I found this bug, just today, in 3.6.2.2, when trying to paste screenshots into a document.

LO Writer placed the first couple of screenshots properly, inline in the document, but for the third (perhaps when the insertion-point was too close to the second screenshot's anchor) it decided to place "absolutely positioned" on the page rather than flowing to the next.

I managed to work around it.

But hey, when I saved & re-opened the documents to verify they were OK before sending (this was actual work, not just a test) the image scaling had been completely lost & they were cropped at page-right with only 3/4 of the image visible. Utterly unusable.

The bug has a big tradition, and it's still present in 4.1.2. I'll attach a non-trivial example where images are much smaller than one page, and they did not overlap until some image and text was changed. Even now reformatting everything does not fix the problem. Why can TeX do it and OpenOffice/LibreOffice not?

Created attachment 89837 [details]
Sample (simplified) text document with images overlapping without intention to do so

(In reply to Ulrich Windl from comment #7)
> Created attachment 89837 [details]
> Sample (simplified) text document with images overlapping without intention
> to do so

Confirmed, but I'm hesitant to set as NEW without comments from QA.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08

I really don't understand why you set the importance of this bus to "minor": For me this bug makes the product unusable, because it fails to do what TeX can do for many many years (process images without hiding one behind the other).

We don't prioritize bugs based on a subjective "this affects ME a lot." This bug can slow down professional quality work but will not completely prevent it. Thus by our objective definition this is minor.

That being said, the priority/severity is just a guidance for developers, they are free to ignore it and if a developer agrees with you they will volunteer to fix it.

This has been confirmed. Comment 4 has clear reproducible steps.

Setting to NEW.

Should have included this:

Ubuntu 14.10 x 64
LibreOffice 4.3.2.2 release

I can confirm that this issue is still present in LibreOffice 5.2.2.2.

I insert a big image in the document. I then insert a second one, and it sits on top of the previous one, so I can only see the second image.

This is with Anchor: To paragraph, and Wrap off.

With Anchor: As character, images behave as expected (they do not overlap), which should probably be the default. It's fine to be able to override images. But I don't think that is the most common use case. One typically want images to be visible in the document.

(In reply to Jose Gómez from comment #17)
> I can confirm that this issue is still present in LibreOffice 5.2.2.2.

Even in 5.2.3.3. The problem may be inherited from OpenOffice, because it never worked (AFAIR).

> With Anchor: As character, images behave as expected (they do not overlap),

Yes, it's the only work-around. However I hate the idea to insert dummy paragraphs or line-breaks, just to have an anchor to position images to.

I really wonder why TeX/LaTeX can position images correctly for decades and LibreOffice seems to be unable also for a decade at least. Is it because everybody is using the work-around described here?

Created attachment 130138 [details]
Screen-shot showing the problem (just in case you don't recognize it)

I wonder: After having seen the problem when two images of the same size were anchored to the same paragraph, could that be part of the problem? In my case both images had a caption and cross-references to them. When both images were exactly lying on top of each other (what isn't allowed anyway), both figures got the same number in the cross-reference (but not in navigator). When I moved the top image off a bit, the number in the cross reference was updated.

Created attachment 137911 [details]
Sample Document (Writer 3.5.3) with overlapping images

Created attachment 147022 [details]
Old bug still present in document created freshly with LO Writer 6.0.6

(In reply to QA Administrators from comment #22)
 
> To make sure we're focusing on the bugs that affect our users today,
> LibreOffice QA is asking bug reporters and confirmers to retest open,
> confirmed bugs which have not been touched for over a year.

I wonder about this type of quality assurance: Do you really think this problem will magically go away, without doing anything to fix it? You add lots of features that actually bring little benefit, but this bug is the most annoying bug in StarOffice/OpenOffic/LibreOffice that forces users to use another product to have text and graphics mixed properly.

Summary: Bug still present in 6.0.6.2.

(In reply to Ulrich Windl from comment #23)
> I wonder about this type of quality assurance: Do you really think this
> problem will magically go away, without doing anything to fix it? You add
> lots of features that actually bring little benefit, but this bug is the
> most annoying bug in StarOffice/OpenOffic/LibreOffice that forces users to
> use another product to have text and graphics mixed properly.

I have replied to these sorts of questions many times, but here goes again: in scientific tests, we consistently achieved around 25% WORKSFORME closing rate for issues re-tested after 1 year of last activity. You can't really argue with that success rate.

This bug is still unresolved in Version 6.2.6.2.

The anchor change from "paragraph" to "as-char" does not work either. Because after that the image gets clipped to height of the line. Is there really nothing to work around this stupid old issue? I am almost desperate about that problem until I found this bug report from 2012. And now I am sad because it is not solvable. I've got documents with hundreds of pages in them and some pages just list some bigger images and they are overlapping each other.
Even using the contour/outline does not help. I was hoping it could help me but it does not.

Regarding 'overlap' of images there are basically two options (a) images should overlap, (b) images should not overlap.
 
This thread has clearly fallen into a somewhat misguided 'bug vs. feature' confusion as if these options are equally relevant. The unquestionable truth is the *simplest* behaviour is to have the images NOT overlap (unless you suggest HTML made the wrong choice?). At this point some well-meaning programmer will typically suggest that is simply my personal view and there is no evidence anyone else thinks the same but frankly that 'option neutrality' rather than informed emphasis is why usability quirks are so pervasive in software.

In summary the the default behaviour of images overlapping from a simple embed or cut-and-paste should take the lesson from HTML and assume the user does NOT want that image to sit under or over some existing image. To have a word processor fall so easily into the opposite behaviour is so egregious it's a bug, not a feature.

As a datapoint I just wasted an hour copying this trivially simple readme into Writer because I was fighting with the default Writer image embedding behaviour (https://github.com/SmartCambridge/milton_road_study/blob/master/report.md)

Created attachment 163323 [details]
Screenshot from LibreOffice 6.4.4.2 (x86)

This is a new variant of the bug:
A heading (large bold font) is mostly hidden under an image that has a caption, but the text should flow around the frame (see setting in screenshot). However it does not.
(When saving the file and reverting from the save file, the heading appears)

Pleas try a new version of LibreOffice. It has a new option "Allow overlap" in the "Wrap" tab of the "Properties"-dialog of the image.

*** Bug 142964 has been marked as a duplicate of this bug. ***

The default behaviour is still "Allow overlap". I think it should be changed as "No overlap" as default. I can't think of the usage of having completely overlapped images as default when inserting several images at once.

I have tested this with LibreOffice Writer ver 7.0.3.1 under Ubuntu 18.04 and Windows 10:

(In reply to Hernan from comment #30)
The issue here is not the default setting; instead the issue is that images still overlap when the setting is "no overlap".

*** Bug 144849 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 149376 ***