it took a little longer than anticipated to look at the files.
First some explanation about Need Appearances.
Normally a PDF should have the visual state of the form fields
generated so that when a reading application views the PDF the visual
appearance can be drawn.
Need Appearances being set to true signals the reading application that
the visual state is incomplete and the application should generate that
on the fly. This is discouraged and deprecated in PDF 2.0 as now the
dependency is no longer on the generating side but on the reading side
(e.g. a reader might not display the form fields at all when there is
no appearance information)
For the file in question is hat incomplete appearance information. The
best would be to fix that prior to merging.
PDFBox 2.0.22 tries to fix that but does that incomplete because of
partially existing information in the source.
2.0.21 and before don't try to fix that.
Unfortunately there is also no way to tell PDFMergerUtility 2.0.22
onwards to skip the fix as the AcroForm getter in PDFMergerUtility uses
the default call.
As a workaround set need apperances to true after the merging has been
completed.
In addition feel free to file a bug report for 2.0.22 onwards.
BR
Maruan
Am Dienstag, dem 06.06.2023 um 18:55 +0000 schrieb
sven.neufe...@ruv.de:
> 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().setNeedAppearanc
> es(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
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
