Hey, thanks for answering! Hum... "setDestinationDocumentInformation" & "setDestinationMetadata" are PDFMergerUtility instance's methods to optionally set metadata on the resulting merged PDF as in "legacyMergeDocuments", as written in the documentation. So I would argue it's unrelated to the actual merging process (so It wouldn't be within the "not all documents are merged" statement scope). Especially since the merged PDF is directly saved to an output stream or file (meaning we would need to load it again in a PDDocument to apply metadata/informations to it), so It would somehow go against the point of this optimized implementation (reducing memory usage).
But if I'm wrong, it would only be very misleading to the API consumer, as I was when I tried to use it, that those two setters are working only in PDFBOX_LEGACY_MODE. It would at least need clarifications in the documentation. I hope we get to the bottom of it :D - JH On Thu, Oct 24, 2024 at 4:06 AM Tilman Hausherr <thaush...@t-online.de> wrote: > > Hi, > > The documentation has this text for OPTIMIZE_RESOURCES_MODE: "Not all > document elements are merged". I suspect that the reasoning was to > minimize what gets merged. > > It turns out that the tickets in which this was introduced are still open: > https://issues.apache.org/jira/browse/PDFBOX-4182 > https://issues.apache.org/jira/browse/PDFBOX-4188 > > Tilman > > On 23.10.2024 15:53, Jean-Hugues Gilbert wrote: > > Hello there, > > I’m currently migrating from PDFBox 2 to PDFBox 3, working like a charm so > > far. > > > > But quite some time ago I’ve saw the PDFMergerUtility wasn’t setting > > destinationDocumentInformation & destinationMetadata in the > > optimizedMergeDocuments before saving the merge to a file, to the > > contrary of the legacyMergeDocuments. > > > > I was obligated to fix that on my side by duplicating the code and add > > this behaviour, but since I’m upgrading to PDFBox 3 and the issue is > > still around, I thought it would be better to contact you all so you > > are aware. > > > > I consider this as a bug, and not a deliberate choice. But I could be > > wrong? Is this expected? > > Thank you for your help! > > - JH > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > > For additional commands, e-mail: users-h...@pdfbox.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: users-h...@pdfbox.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
