Good point, but the issue is the same, even I try to "merge" one single 
document or more ones.
I wrote a little example application called "PDFMerge.java". Please find at the 
end at that message. 
The behaviour is fine for that case, when I removed the line 
"acroForm.setNeedAppearances(false);" within the 
AcroFormGenerateAppearancesProcessor class.

The process how we use PDFBox is:

1. PDF files to be merged are created on the server side
2. PDF files are read and merged together
3. The merged PDF document is delivered to the client
4. The client saves then the document locally
5. Then the document will be opened by a standard application, e.g. Adobe 
Reader, and printed out if needed

I could find out, that the difference in the documents is produced at step 2.
I also tried to set the value manually within the PDFMergerUtility class

        sourceDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);

But it turned out that this entry will be overridden by the 
AcroFormGenerateAppearancesProcessor.

Hope that'll help you!

Kind regards
Sven Neufeind

### PDFMerge.java

package org.apache.pdfbox.examples.interactive.form;

import org.apache.pdfbox.io.MemoryUsageSetting;
import org.apache.pdfbox.multipdf.PDFMergerUtility;

import java.io.*;
import java.util.Arrays;

public class PDFMerge {

    public static void main(final String[] args) throws IOException {
        final var inputFiles = Arrays.asList(
                "origin.pdf"
        );
        final var outputFile = "target/merged.pdf";

        final var memoryUsageSetting = MemoryUsageSetting.setupMainMemoryOnly();
        final var pdfMergerUtility = new PDFMergerUtility();
        final var dokumentOutputStream = new ByteArrayOutputStream();
        pdfMergerUtility.setDestinationStream(dokumentOutputStream);

        inputFiles.forEach(file -> {
            try (final var fis = new FileInputStream(file)) {
                pdfMergerUtility.addSource(new 
ByteArrayInputStream(fis.readAllBytes()));
            } catch (Exception e) {
                e.printStackTrace();
            }
        });

        pdfMergerUtility.mergeDocuments(memoryUsageSetting);

        try (final var outputStream = new FileOutputStream(outputFile)) {
            System.out.println("creating output file : " + outputFile);
            dokumentOutputStream.writeTo(outputStream);
            dokumentOutputStream.close();
        }

    }
}

-----Ursprüngliche Nachricht-----
Von: Tilman Hausherr <thaush...@t-online.de> 
Gesendet: Dienstag, 6. Juni 2023 19:47
An: users@pdfbox.apache.org
Betreff: Re: [Bug] (Radio) Buttons can not be printed in a merged PDF

I'm wondering whether maybe the documents have differents settings of 
the /NeedAppearances/ entry, and after merge it is set in a way that is 
bad for you.

Does the rendering work properly if you change the entry manually? 
doc.getDocumentCatalog().getAcroForm().setNeedAppearances()

Also, could it be you're rendering and THEN merging, i.e. from the same 
PDDocument object?

Tilman

On 06.06.2023 13:47, sven.neufe...@ruv.de wrote:
>
> Heys guys,
>
> we're having an issue with some of our PDF documents that contains 
> interactive fields like Radio Buttons. In some cases we’ve to merge 
> PDF documents together (using the PDFMergerUtility) and when we try to 
> print that merged document these Button elements are not rendered 
> correctly, when using Apache PDFBox >= 2.0.22. Using the version 
> 2.0.21 the buttons are rendered correctly.
>
> I’m pretty new in the world of how PDF files work under the hood and 
> how the PDF structure and fields is defined in the standard. So I did 
> some research and could find out the reason for this misbehavior.
>
> It looks like that issue had been introduced with this commit: 
> https://github.com/apache/pdfbox/commit/fe00cd3870f6d9ec27fcb55c89409b420ade0826
>
> In the origin document (before entering the merge step) the 
> /NeedAppearances/ entry is set to true, but after the merge step the 
> entry’s changed to be false.
>
> I could figure out that this line of code is the reason for that: 
> https://github.com/apache/pdfbox/blob/fe00cd3870f6d9ec27fcb55c89409b420ade0826/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/fixup/processor/AcroFormGenerateAppearancesProcessor.java#L55
>
> Is that an intended behaviour or is that an unintentionally sideeffect?
>
> Kind regards
>
> Sven Neufeind
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to