(Partially copied from https://bugs.freedesktop.org/show_bug.cgi?id=87044#c13 ) The basic design of reports is "formatting by tables": each section of the report is a table, and cells are sized (and merged if need be) to place everything at the position it should be. The general principle is that each control is its own table cell. Note that this has the effect of forbidding controls to overlap in any way, as table cells are not allowed to overlap. *But* charts and shapes are different. They are not their own table cell. Charts are always (structurally) placed in the first column first row (cell A1), *but* their position / size attributes may lead to them "overflowing" from the cell and actually being placed "over" other cells; and quite possibly actually not being (presentationally, in the rendered document) a single pixel in the A1 cell they are placed in. 1) This does have the effect of allowing them to overlap with other controls. This is probably "by design" for shapes, but I'm not that sure about charts. 2) The drag'n drop code refuses to have charts overlap with other controls. To have them overlap, one has to edit the size/position properties numerically (that is, in the properties side-pane that F4 brings up). Either the drag'n drop code should allow it, or it should be completely forbidden. 3) Test drag'n drop on shapes. 4) It *also* has the effect that they are always placed on the page that the first row is placed in, even when the table is split over several pages, and that the "right" place for the chart would be another page. This seems to be (nearly?) exactly bug 52126, and looks related to bug 83354, bug 55202 and possibly also bug 73707. This is definitely a bug. How to fix that? We could improve on the situation by placing them, something like: - In the "closest" cell that exists anyway. Closest in any direction. - In the "closest" cell that is to the upper left of the desired position. - If the float's exact position is into an empty cell anyway, then split that cell so that the float is exactly at the upper left of that cell. Another way would be for Writer to treat overflows from cells into *next* page instead of into the margin / footer of the page. Is that an option? Discuss with a writer dev.
Adding self to CC if not already on
Have tried to position a shape for a big Detail-section. It's impossible to position it right out of the first page, because it is anchored to the first element of the Detail-section. Problem would be solved if we would anchor shapes to the first element of a section, which is shown on a new page. I will add an attachment to show the wrong position on second page of Detail-section, the right position on the first page of Detail-section.
Created attachment 122283 [details] Open the report. Have a look at the red shape (first page) and the blue shape (second page) Pagebreak to second page is performed by a labelfield. So the labelfields and textfields on the second page will be shown at the right place. Only the blue rectangle on the second page couldn't be positioned the right way. It floats, depend on header, footer, margins. Shows also the wrong y-position to the first paragraph of the Detail-section, if you want to edit the executed report.