Bug Hunting Session
Bug 84913 - Repagination on PDF export changes page number in master document with hidden sections
Summary: Repagination on PDF export changes page number in master document with hidden...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.3 Daily
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
Depends on:
Blocks: PDF-Export Repagination Writer-Master-Doc
  Show dependency treegraph
 
Reported: 2014-10-11 13:32 UTC by Daniel Grigoras
Modified: 2019-09-20 03:05 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Grigoras 2014-10-11 13:32:41 UTC
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
Comment 1 tommy27 2014-10-14 05:12:04 UTC
test file needed. I set status to NEEDINFO.
revert status to UNCONFIRMED when you provide requested infos.
Comment 2 Daniel Grigoras 2014-10-14 07:00:06 UTC
(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
Comment 3 tommy27 2014-10-14 08:46:44 UTC
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?
Comment 4 Daniel Grigoras 2014-10-14 08:52:09 UTC
(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.
Comment 5 tommy27 2014-10-14 09:07:45 UTC
(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?
Comment 6 Daniel Grigoras 2014-10-14 09:45:17 UTC
(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
Comment 7 tommy27 2014-10-14 12:28:33 UTC
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
Comment 8 Daniel Grigoras 2014-10-14 13:01:04 UTC
(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?
Comment 9 Daniel Grigoras 2014-10-14 16:32:30 UTC
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.
Comment 10 Daniel Grigoras 2014-10-14 16:35:25 UTC
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.
Comment 11 tommy27 2014-10-14 20:07:15 UTC
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
Comment 12 A (Andy) 2014-10-25 13:20:06 UTC
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?
Comment 13 Daniel Grigoras 2014-10-25 13:29:52 UTC
(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.
Comment 14 tommy27 2014-11-24 11:45:39 UTC
have you tried 4.3.4.1 
is issue stille there?
Comment 15 Daniel Grigoras 2014-11-24 12:51:09 UTC
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.
Comment 16 Daniel Grigoras 2014-11-24 13:04:20 UTC
"sudo apt-get install libreoffice" installs version 4.3.3~rc2
Comment 17 Daniel Grigoras 2014-11-24 13:06:32 UTC
"sudo dpkg -i *.deb" doesn't help
Comment 18 Joel Madero 2014-12-06 19:15:51 UTC
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.
Comment 19 Buovjaga 2015-07-26 17:59:08 UTC
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
Comment 20 Daniel Grigoras 2015-07-30 09:05:26 UTC
(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."
Comment 21 Buovjaga 2015-07-30 09:08:32 UTC
(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.
Comment 22 Daniel Grigoras 2015-07-30 09:12:27 UTC
(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
Comment 23 Buovjaga 2015-07-30 09:19:44 UTC
(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.
Comment 24 Daniel Grigoras 2015-07-30 10:09:00 UTC
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.
Comment 25 tommy27 2015-07-30 10:15:50 UTC
(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.
Comment 26 Buovjaga 2015-07-30 14:48:44 UTC
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)
Comment 27 Daniel Grigoras 2015-07-30 15:00:44 UTC
(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.
Comment 28 Daniel Grigoras 2015-07-30 15:02:47 UTC
(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.
Comment 29 QA Administrators 2018-05-13 02:30:48 UTC Comment hidden (obsolete)
Comment 30 Drew Jensen 2018-09-19 12:22:02 UTC
(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.
Comment 31 Roman Kuznetsov 2018-09-19 22:02:07 UTC
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
Comment 32 QA Administrators 2019-09-20 03:05:17 UTC
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