Hi, I work with a 2000 page master document and when I export it to PDF repagination is carried out, which somehow changes the increases the page count and so the page number in the table of contents does not correspond anymore with the real page number, though the link work. I hope that you will allow disabling of repagination on export of PDFs or fix this repagination issue I encounter. Regards, Daniel
test file needed. I set status to NEEDINFO. revert status to UNCONFIRMED when you provide requested infos.
(In reply to tommy27 from comment #1) > test file needed. I set status to NEEDINFO. > revert status to UNCONFIRMED when you provide requested infos. All the documents I work with contain confidential and proprietary data and information. However, I remember creating a sample master doc a while ago, which you can download from here: https://www.dropbox.com/s/vz43d9x0v1t3fxr/master_for_support.zip?dl=0
thanks. I got the .odm master document and the other .odt file. please tell me "step by step" what I have to do in order to reproduce the bug. P.S. which LibO version are you using?
(In reply to tommy27 from comment #3) > thanks. I got the .odm master document and the other .odt file. > > please tell me "step by step" what I have to do in order to reproduce the > bug. > > P.S. which LibO version are you using? I'm using version 4.3.2.2, build 430m0(Build:2), which should be the latest stable version. To reproduce the bug just insert all of the subdocuments, i.e. the ODTs into the master document (ODM). Wait for it to reflow the text. Update the TOC and then export to PDF. Repagination is carried out and then the PDF is exported. Looking in the PDF you will see that the page numbers mentioned in the TOC for the headings does not correspond anymore to the real page number.
(In reply to Darius Daniel Grigoras from comment #4) > ... > I'm using version 4.3.2.2, build 430m0(Build:2), which should be the latest > stable version. is it the first version you saw the bug or was present even in older releases? > > To reproduce the bug just insert all of the subdocuments, i.e. the ODTs into > the master document (ODM). I'm not familiar with master documents, what should I do to insert the .odt inside the .odm? drag and drop or what else?
(In reply to tommy27 from comment #5) > (In reply to Darius Daniel Grigoras from comment #4) > > 1. is it the first version you saw the bug or was present even in older > releases? > > > 2. I'm not familiar with master documents, what should I do to insert the .odt > inside the .odm? drag and drop or what else? 1. This is an old bug. 2. Insert->File
tested under Win7x64 using LibO 4.3.2.2 I dragged and dropped the .odt files into the .odm and the final document was 2285 pages. then I exported it to .pdf and the output was still 2285 pages. maybe I'm missing something but a smaller test case would be better in order to easier spot the difference between source file and output
(In reply to tommy27 from comment #7) > tested under Win7x64 using LibO 4.3.2.2 > > I dragged and dropped the .odt files into the .odm and the final document > was 2285 pages. then I exported it to .pdf and the output was still 2285 > pages. > > maybe I'm missing something but a smaller test case would be better in order > to easier spot the difference between source file and output Did you first update the table of contents before exporting the PDF?
Indeed, with that old anonymized version that I created about two months ago for use on the OpenOffice forum, things work well. However,that did not have any hidden sections defined. Please download a sample that has hidden sections defined in the subdocuments from here: https://www.dropbox.com/s/vz43d9x0v1t3fxr/master_for_support.zip?dl=0 You will also find a PDF version in which the headings in the TOC are not pointed to the right page. You can now reproduce this easily. Just open the master document in which the subdocuments are already linked, click update links when asked, then updated TOC and export to PDF. You will see that repagination takes longer and that the page count in the PDF is different than the one reported in the master document before exporting to PDF. So bottom line, this page number issue is caused by the use of hidden sections and repagination.
Moreover, not only that the page count does not correspond, but some or many of the pages at the end are not even exported into the PDF. From ten tries only once were all of the pages exported in my experience, and even then, the page count still differed from the one reported before exporting to PDF and the ones mentioned in the TOC.
please do not set status NEW to your own bugs. that status can be set only after an independent confirmation of the bug you submitted. reverting to UNCONFIRMED
Is this maybe related to the bug reports 85438 and 85435? There you have sample files leading to different number of pages (54 vs. 55)? Is yes, we could maybe close this bug report and reopen it if it would still persist after bug fixes of these both bugs?
(In reply to A (Andy) from comment #12) > Is this maybe related to the bug reports 85438 and 85435? There you have > sample files leading to different number of pages (54 vs. 55)? > Is yes, we could maybe close this bug report and reopen it if it would still > persist after bug fixes of these both bugs? It may be related to those, though I doubt it. Actually, this has to do with hidden sections. I had to manually delete all hidden sections to produce the final PDF, as in the absence of hidden sections repagination did not occur and the page count was the same in the PDF as in the ODT. As I have to produce updated PDFs regularly, it's time-consuming and annoying to delete the hidden sections each time.
have you tried 4.3.4.1 is issue stille there?
I just couldn't find a way to update to the latest version on Ubuntu, as using the latest version on Windows I receive the Error message "Bad allocation", and LibreOffice crashes.
"sudo apt-get install libreoffice" installs version 4.3.3~rc2
"sudo dpkg -i *.deb" doesn't help
Please do not mess with the priority/severity - they have particular meanings and this does not in any way qualify as a blocker. Prioritizing your own bugs is not suggested as it's hard to be objective. Setting to: Major - apparent loss of data (page number) on export. Medium Again please don't change the priority again, it won't help get it fixed and it will only annoy developers and QA who try to be unbiased and objective in setting priorities.
You can get the latest stable from a PPA maintained by the Ubuntu team: sudo add-apt-repository -y ppa:libreoffice/ppa sudo apt-get update sudo apt-get dist-upgrade You can also install 5.0 release candidates in parallel, if you wish: https://wiki.documentfoundation.org/Installing_in_parallel
(In reply to Beluga from comment #19) > You can get the latest stable from a PPA maintained by the Ubuntu team: > > sudo add-apt-repository -y ppa:libreoffice/ppa > > sudo apt-get update > > sudo apt-get dist-upgrade > > You can also install 5.0 release candidates in parallel, if you wish: > https://wiki.documentfoundation.org/Installing_in_parallel Entering: "sudo add-apt-repository -y ppa:libreoffice/ppa" I get: "E: Command line option 'y' [from -y] is not known."
(In reply to Darius Daniel Grigoras from comment #20) > Entering: "sudo add-apt-repository -y ppa:libreoffice/ppa" > > I get: "E: Command line option 'y' [from -y] is not known." Ok that sounds weird, but you can leave the -y out. It is just supposed to answer "Yes" automatically for you.
(In reply to Beluga from comment #21) > (In reply to Darius Daniel Grigoras from comment #20) > > Entering: "sudo add-apt-repository -y ppa:libreoffice/ppa" > > > > I get: "E: Command line option 'y' [from -y] is not known." > > Ok that sounds weird, but you can leave the -y out. It is just supposed to > answer "Yes" automatically for you. Entering: "sudo add-apt repository ppa:libreoffice/ppa" or "sudo add-apt-repository ppa:libreoffice/ppa" (notice the dash between 'apt' and 'repository') I get: "E: Invalid operation repository" or "sudo: apt-get-repository: command not found", respectively
(In reply to Darius Daniel Grigoras from comment #22) > (In reply to Beluga from comment #21) > > (In reply to Darius Daniel Grigoras from comment #20) > > > Entering: "sudo add-apt-repository -y ppa:libreoffice/ppa" > > > > > > I get: "E: Command line option 'y' [from -y] is not known." > > > > Ok that sounds weird, but you can leave the -y out. It is just supposed to > > answer "Yes" automatically for you. > > Entering: "sudo add-apt repository ppa:libreoffice/ppa" or "sudo > add-apt-repository ppa:libreoffice/ppa" (notice the dash between 'apt' and > 'repository') > > I get: "E: Invalid operation repository" or "sudo: apt-get-repository: > command not found", respectively It seems you have written the command and made a typo: apt-get-repository instead of add-apt-repository.
Well, I've upgraded and repagination is still an issue. After repagination, the page numbers in the Table of Contents do not correspond anymore with the real page numbers in the document. I noticed that this is due to the hidden sections defined in the subdocuments. So I have a masterdocument which links subdocuments that have hidden sections. These hidden sections are visible in the subdocuments, but are hidden in the masterdocument by means of a variable: InternalUse==0/1.
(In reply to tommy27 from comment #11) > please do not set status NEW to your own bugs. > that status can be set only after an independent confirmation of the bug you > submitted. reverting to UNCONFIRMED I revert status to UNCONFIRMED for the second time please respect procedures.
On opening the .odm it simply asked, if I wanted to update the linked data. After waiting for a (long) while, the document loaded and I could see the .odts in the navigator. I updated the TOC. Then I exported the PDF (it must have taken over 1 hour). Confirmed the inconsistent page count in the PDF comparing with the TOC. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 902255645328efde34ddf62227c8278e8dd61ff0 TinderBox: Win-x86@39, Branch:master, Time: 2015-07-30_03:52:07 Locale: en-US (fi_FI)
(In reply to Beluga from comment #26) It didn't take that long on my side, but I have an Intel Core i7-4770k, 256GB SDD and 16GB of RAM. The loading of the subdocuments took around 5 minutes or less and the PDF Export around 5 minutes or a bit more.
(In reply to Darius Daniel Grigoras from comment #27) > (In reply to Beluga from comment #26) > > It didn't take that long on my side, but I have an Intel Core i7-4770k, > 256GB SDD and 16GB of RAM. The loading of the subdocuments took around 5 > minutes or less and the PDF Export around 5 minutes or a bit more. PS: I can only work with masterdocuments on Linux (Ubuntu 14 64-bit in my case). On Windows 7 64-bit LibreOffice crashes during the loading of the subdocuments.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #29) > ** 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. > This anomaly was mentioned in a recent post on the documentation mailing list as having bit during the production of the 6.0 Getting Started Guide. The files with the hidden sections, and the resulting master document, are still available for testing. If not on the TDF nextcloud server still then in a local zip file on my (and others) machine.
still present in Version: 6.1.1.2 (x64) Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: ru-RU (ru_RU); Calc: CL
Dear Daniel Grigoras, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 157132 [details] File with hidded section, mess PDF bookmarks
Confirmed the loss of bookmarks as TOC in PDF export even with a ODT (Writer) file. No need for master document. The attached file has a section wrapping from "copyright" to table of contents, and is hidden when variable "book eq 1" . The variable book is in the fist page in front of "Using..." and displays 1. On exporting to PDF, the hidden section is omitted but the bookmark for section entry "Status Bar" should have indicated page 5 and now displays page 10. Bookmarks up to page 4 are correct.
when did this problem start to show up, is that known?
(In reply to Olivier Hallot from comment #34) > Confirmed the loss of bookmarks as TOC in PDF export even with a ODT > (Writer) file. No need for master document. > > The attached file has a section wrapping from "copyright" to table of > contents, and is hidden when variable "book eq 1" . The variable book is in > the fist page in front of "Using..." and displays 1. > > On exporting to PDF, the hidden section is omitted but the bookmark for > section entry "Status Bar" should have indicated page 5 and now displays > page 10. > > Bookmarks up to page 4 are correct. It appears this is not the same as the original problem. Status bar bookmark leads to page 5 with version 4.4.7 (also confirmed working in 3.3.0 and 3.5.0). The original problem was already seen in 4.3. Please open a new report for your issue while adding me to Cc. I will bibisect it later. Btw. we cannot re-test the original report because the Dropbox links are dead
Off-topic issue bibisected and reported as bug 130151
The Dropbox link doesn't work anymore...
Closing as the test files are gone.