Looks good. I modified getAllKids() so that it returns the same output as your workaround, rather than applying the workaround to the output. It’s now in the 1.8.7 and 2.0 trunks.
-- John On 8 Jul 2014, at 10:53, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: > yes - in PDFBOX-1533 I added a description for a workaround I plan to put in. > WDYT? > > BR > Maruan > > Am 08.07.2014 um 19:49 schrieb John Hewson <j...@jahewson.com>: > >> In Adobe Acrobat this file has only two pages, so as noted the root of the >> page tree is invalid: >> >> /Kids [3 0 R, 3 0 R, 3 0 R] >> >> Acrobat is ignoring these extra pages, so the fix for PDFBox should be to >> ignore repeated objects in the page tree. >> >> -- John >> >> On 7 Jul 2014, at 14:05, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: >> >>> the issue is because part1.pdf in PDFBOX-1533 references the same 2 pages 3 >>> times within the document catalog (/Kids [3 0 R, 3 0 R, 3 0 R]). Could you >>> attach a sample pdf to PDFBOX-1533 to verify that your issue has the same >>> cause or verify it for yourself? >>> >>> We are using PDFBox for merging documents ourselves successfully. Obviously >>> this file would need some special treatment. >>> >>> BR >>> Maruan >>> >>> Am 07.07.2014 um 11:31 schrieb Aleksander Blomskøld <aleks...@gmail.com>: >>> >>>> Hi, >>>> >>>> We're using PDFBox for PDF validation and PDF merging in a backend >>>> invoicing system. It's working pretty well for most of the time, but right >>>> now we're having some unhappy customers because of >>>> https://issues.apache.org/jira/browse/PDFBOX-1533. >>>> >>>> As it's important for us to have this fixed pretty soon, we're wondering if >>>> anyone of you would be willing to fix this issue for pay. If so, please >>>> contact me so we can work out the details. >>>> >>>> >>>> Regards, >>>> >>>> Aleksander Blomskøld >>> >> >
