https://bugs.freedesktop.org/show_bug.cgi?id=87430
Bug ID: 87430
Summary: REPORTBUILDER: fix placing of floats (shapes & charts)
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: medium
Component: Database
Assignee: [email protected]
Reporter: [email protected]
Blocks: 52126, 55202, 73707, 83354
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
