Created attachment 64245 [details] Two reports, both positioned correct while edition - Position Y always 17cm. For a report, which needs positioning of elements at the second page, I put the details-range over 39,3 cm. Header and footer were both 3 cm, margins both 2 cm. So also the second page had to be filled completly with the details of the first row of data. When I see "Position Y" in the properties, it shows always 17 cm - for all elements, which are position over 17 cm from above. So I have positioned the elements only with the mouse or with arraow-keys. But then I could see, that a inserted shape is positioned not the same way as a label-field. When editing the report, both are positioned at the same Y-Position. But when I perform the report, it shows the shape with a big distance above the label-field. When I take away header an footer, the distance isn't so far and the lable-field is nearly positioned at the right place. I have created an attachment, which shows two reports, positioned correct when editing - not correct, when performed.
Created attachment 65022 [details] Shows the design of the report over one page and the output. Could be there is more than one bug in this report. The description shows, what could happen, when you try to make a report with a section, which needs more than one page: - The positioned couldn't set with numbers in the properties. Shows always "17cm" for a position over 17cm. - Shapes, could be also pictures, couldn't be positioned right on the second page. They move to the next text-field or data-field above them. When you add a group in the report, they move outside the report! - Header and footer aren't shown together with the first section. - Fields aren't positioned right on second page together with header and footer. So the only way to geht a nearly right design over one page is - not to use any shapes or pictures - not to use header or footer.
Just testing all bugs from Report-Builder. This bug first appears in the oldest available version of LO, 3.3.0 beta1. So I set the first available bugzilla-version, 3.3.0 release.
Adding self to CC if not already on
** Please read this message in its entirety before responding ** 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. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT: - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
Bug still exists with LO 5.1.0.3, OpenSUSE 42.1 Leap, 64bit rpm Linux. Position is now shown with correct value (Value, which is set in Report-Builder - not always 17cm as written in the description of the report.). Will see if I could close this bug and open two new bugs - one for position of shapes and one for position of textfields.
I have tested a little bit more. 1) Position is shown correct now and doesn't end at "17 cm". 2) Position on second page is right for textfield, if the first field of the second page is positioned at top of the page. ReportBuilder sets a document by tables. If there isn't enough place at the first page for the difference between last field of the first and first field of the second page the whole row of the table is set to the second page. There could be constructed a workaround: Create a little labelfield without content. Set this textfield to the top of the second page. All fields on the second page will be shown at correct position. All this works only with textfields and labelfields. Shapes couldn't positioned right, because they are set independent from any table. Anchor for this fields are paragraphs. I will set this bug as "Resolved" and "Worksforme"