[ https://issues.apache.org/jira/browse/PDFBOX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938481#comment-17938481 ]
Andreas Lehmkühler commented on PDFBOX-5978: -------------------------------------------- The behaviour is correct. According to the spec a file that has never been incrementally updated, the cross-reference section shall contain only one subsection, whose object numbering begins at 0. PDFBOX_4952 added some mechanism to fill possible gaps with free objects. A splitted pdf is a new pdf so that we have to follow that rule. IMHO the only way to ged rid of those entries is to reassign new object numbers to all indirect objects, starting at 1 > Issue when saving pdf with NO_COMPRESSION > ----------------------------------------- > > Key: PDFBOX-5978 > URL: https://issues.apache.org/jira/browse/PDFBOX-5978 > Project: PDFBox > Issue Type: Bug > Components: Writing > Affects Versions: 3.0.4 PDFBox > Reporter: Yannick Hanus > Assignee: Andreas Lehmkühler > Priority: Minor > Attachments: NO_COMPRESSION.65535f.png, PDFJS-17784.pdf, > PDFJS-17784_unc.pdf, Test_NO_COMPRESSION.java, output.part.1.pdf > > > Java version : 21 > Pdfbox version : 3.0.4 > > When a pdf is saved with option CompressParameters.NO_COMPRESSION, useless > lines like > _nnnnnnnnnn_ 65535 f > are added to xref section > When splitting a pdf, this side effect seems cumulative when saving each part. > Not really relevant when saving only one pdf but when splitting a pdf to 5000 > parts, it becomes huge. > You can reproduce the issue with any pdf > Current workaround to fix this issue : open and save the produced pdf(s) with > itextpdf 5.5.13.4 remove the useless lines like _nnnnnnnnnn_ 65535 f : > > {code:java} > try (InputStream is = new FileInputStream(tempFile)) { > PdfReader pdfReader = new PdfReader(is); > PdfStamper pdfStamper = new PdfStamper(pdfReader, new > FileOutputStream(targetSplitFile)); > pdfStamper.close(); > pdfReader.close(); > } catch (Exception e) { > throw new RuntimeException("Unable to save with itext " + > targetSplitFile, e); > } > {code} > You can use the attached class to reproduce de issue. > Just pass the absolute path to a pdf as argument to the class -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org