I have a large document with a master and 20 chapters, each as separate files. When I try to export certain pages, it gets the wrong pages. Export PDF and Tools->Update->Page Formatting have a different idea of when the pages need to be re-formatted. Please investigate and pick one so that the same page layout occurs when either of these options is chosen! I have tried Tools->Update->Page Formatting, which, in this case, didn't do anything. Why when I try to export PDF, the progress bar at the bottom of the window shows that it's reformatting, going over and over the same sections. Eventually, it outputs a PDF file, but, the reformatting changes the page layout, so the pages just output are wrong. It took running Export PDF SEVEN times before the page layout seemed stable! I get the page numbers by using the Navigator to go to the desired pages, writing the pages down, and copying the page ranges into the Export PDF dialog. For example, each of the following lines contain the range of pages (for the exact same content!) that I needed to export. Each time, even though Tools->Update->Page Formatting indicated that no page re-formatting needed to be done, Export PDF re-layed out the pages, and changed the page numbers to what follows. 275-291,307-355 275-290 (when I saw the pages being re-layed out, I didn't trust it, so I re-exported.) 273-292,308-355 275-293,309-356 283-298,314-361 273-290,306-353 273-289,305-352 I also have "Export automatically inserted blank pages" enabled, else the pages are REALLY off (bug #57710). This bug is to find out why Export PDF and Tools->Update->Page Formatting have a different idea of when the pages need to be re-formatted. Is there any reason for the users to get different page layouts if these different commands are selected? It's frustrating to see the pages and their page numbers for pages to be exported, verify that no re-layout needs to be done, and then try to export those pages and have the exporter change the page numbers and then export the old page numbers!
We need a test document to actually see what you're talking about or reproducible steps with a smaller document. Marking as NEEDINFO, we'll either need the document or the steps, otherwise really hard to triage the bug. Once you get us the info (either attachments or steps to do a really simple test case) with "expected result" and "observed result" mark as UNCONFIRMED and we'll look at it. Sorry that you're having an issue. Also have you tried printing to file (file -> Print -> Options tab -> Print to File (check it) then print, you'll get a dialog to name the file. The output of this should be IDENTICAL to what you'd print and see on screen.
Unfortunately, I've been unable to create a "clean" test document that demonstrates the problem. The one I'm working with is large and proprietary and I'm working under a deadline to get it published to the rest of the engineering team. (I spent an hour trying to create a test case, but to no avail.) My request is for a ***code inspection***, to find out why Tools->Update->Page Formatting does something different from File->Export PDF when determining when to re-format the pages. But when the 1st command doesn't do anything, implying that the document doesn't need to be re-formatted, Export PDF will still reformat and the pages I need to print move to new page numbers! If I execute Export PDF a 2nd, 3rd, 4th time, it will reformat EVERY time and get DIFFERENT page results each time. (I'm capitalizing because there are no italics here, and so that those important points are emphasized. I'm not caps-yelling.)
marking as UNCONFIRMED - going to try to get an expert to get involved here
@Michael - any pointers on how we can move forward with this one - seems quite bad but no test document can be provided
I have to put this back in NEEDINFO as without the document, really nothing we can do. That being said I have found a workaround for others with classified documents: do a find replace and replace letters with random other letters or phrases. Do this quite a few times and you'll provide us with a document that is unreadable but displays the problem. Once an attachment is made mark as UNCONFIRMED and we'll go from there.
Created attachment 87455 [details] sample document with large tables I attached a large document containing a lot of tables that split across several pages. The bug is VERY irritating to me but is also very hard to make it happen consistently. I'm not convinced that it has anything to do specifically with the PDF export function. It seems to be more with just the page formatting function which is also called when doing a PDF export. In testing this, I can fix the document so the tables flow perfectly from one page to the next, do a page format update and everything is still OK. Then I close the document and re-open it and everything still looks OK. Then I do a page re-format and it messes up. You can get the table to split properly across the pages instead of leaving big gaps just by adding rows. Often times just pressing ctrl-z then to undo the changes is enough to keep the tables flowing properly until you re-open the document and do another page format. On the document I attached, the split problem was showing on pages 11 and 22 (in addition to other places) the last time I opened it. This problem occurs under Linux and Windows XP.
Same problem – different problem? I opened the doc with 4.1.3.2 under F20 beta. I hit F5 and go to page 150. This takes me to page 149!! Press Next page and, at the bottom of page 150 there are 3 footnotes all tagged “1”. Press PREV a few times (5 times) and NEXT 5 times. The footnotes are now labelled 1 and 2 as I think they should be! Delete footnotes. Insert 2 more footnotes on page 150. Close doc. Reopen and you go directly to page 150 where there are 3 footnotes. So the problem is in the ODT doc as Steve suggests. Create a blank doc and use the “Lorem Ipsum” generator to add +150 pages. Go to page 150 and add footnotes. Back to page 1. Save a close doc. Reopen and jump to page 150 – all is good. No tables included. If Steve could advise how he created the sample doc then it might provide a clue where the problem lies. I would categorise this as NEEDINFO - thoughts?
The sample document I attached was simply made by creating a new document, adding a table & a heading and copying & pasting those multiple times into the document, then entering the data with footnotes into the cells.
I strongly suspect that this bug is a duplicate of bug 72424. Both utilize tables and complain of paging that changes.
Not a major bug - lowering to: Normal: Can prevent high quality/professional work Medium: Default seems appropriate here For reference please see: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
@David I tried exporting to PDF your big text file and I see apparently no change using LibO 4.2.5.2 is issue still valid or am I missing something? @Steve Kelem is your bug reproducible with latest 4.2.x release?
It looks like there have been some things that have changed in 4.3.0.2. It doesn't look like exporting to a pdf wants to recalculate the page formatting now if it's already been done. But in checking through the document there are many times when the footnote numbering is not correct. As an example, after the page formatting is done, on page 196, on my system, the first footnote is labeled #3 and the second one is labeled #1. This document was originally created as an .odt document. It was not converted from another file type.
please file a new bug about wrong footnote numbers, or any other problem with this document that is unrelated to formatting the wrong pages on PDF export. (you don't need to upload the document again, providing a link to the attachment here is enough)
I set status to NEEDINFO since we are still waiting about feedback from the original reporter, Steve Kalem, if he's still reproducing his bug. regarding the footnote issues, please David follow Micheal's advice and file a new report.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Message generated on: 2015-02-18
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker -- The LibreOffice QA Team This NEEDINFO Message was generated on: 2015-04-01 Warm Regards, QA Team