You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Sv...@ruv.de on 2023/06/06 11:47:32 UTC
[Bug] (Radio) Buttons can not be printed in a merged PDF
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
Re: [Bug] (Radio) Buttons can not be printed in a merged PDF
Posted by "sahyoun@fileaffairs.de" <sa...@fileaffairs.de>.
Am Dienstag, dem 06.06.2023 um 18:27 +0000 schrieb
Sven.Neufeind@ruv.de:
> I used different applications, like Microsoft Edge, Google Chrome and
> Adobe Reader DC to render the PDF file, but the behaviour is the
> same.
is it possible to share the original and merged PDF? Please put it onto
a public location as the mailing list doesn't support attachments. You
can also send it to me directly. Note that I will share my findings.
NeedAppearances set enforces the viewing application to generate the
visible representation /the appearance/ of the from widgets on the fly.
But it's discouraged.
The commit you mentioned should generate the appearance but I'd need to
look at the original and merged version to verify.
BR
Maruan
>
> Kind regards
> Sven Neufeind
>
>
> -----Ursprüngliche Nachricht-----
> Von: sahyoun@fileaffairs.de <sa...@fileaffairs.de>
> Gesendet: Dienstag, 6. Juni 2023 19:22
> An: users@pdfbox.apache.org
> Betreff: Re: [Bug] (Radio) Buttons can not be printed in a merged PDF
>
>
>
> Am Dienstag, dem 06.06.2023 um 11:47 +0000 schrieb
> Sven.Neufeind@ruv.de:
> >
> >
> >
> > 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.
>
> How do you render the PDF? From which application?
>
> BR
> Maruan
>
> >
> > 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/fe00cd3870f6d9ec27fcb5
> > 5c89409b420ade0826
> >
> > In the origin document (before entering the merge step)
> > theNeedAppearances 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/fe00cd3870f6d9ec27fcb55c89
> > 409b420ade0826/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/fixup
> > /p
> > rocessor/AcroFormGenerateAppearancesProcessor.java#L55
> >
> > Is that an intended behaviour or is that an unintentionally
> > sideeffect?
> >
> >
> > Kind regards
> >
> > Sven Neufeind
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
AW: [Bug] (Radio) Buttons can not be printed in a merged PDF
Posted by Sv...@ruv.de.
I used different applications, like Microsoft Edge, Google Chrome and Adobe Reader DC to render the PDF file, but the behaviour is the same.
Kind regards
Sven Neufeind
-----Ursprüngliche Nachricht-----
Von: sahyoun@fileaffairs.de <sa...@fileaffairs.de>
Gesendet: Dienstag, 6. Juni 2023 19:22
An: users@pdfbox.apache.org
Betreff: Re: [Bug] (Radio) Buttons can not be printed in a merged PDF
Am Dienstag, dem 06.06.2023 um 11:47 +0000 schrieb
Sven.Neufeind@ruv.de:
>
>
>
> 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.
How do you render the PDF? From which application?
BR
Maruan
>
> 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/fe00cd3870f6d9ec27fcb5
> 5c89409b420ade0826
>
> In the origin document (before entering the merge step)
> theNeedAppearances 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/fe00cd3870f6d9ec27fcb55c89
> 409b420ade0826/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/fixup/p
> rocessor/AcroFormGenerateAppearancesProcessor.java#L55
>
> Is that an intended behaviour or is that an unintentionally
> sideeffect?
>
>
> Kind regards
>
> Sven Neufeind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: [Bug] (Radio) Buttons can not be printed in a merged PDF
Posted by "sahyoun@fileaffairs.de" <sa...@fileaffairs.de>.
Am Dienstag, dem 06.06.2023 um 11:47 +0000 schrieb
Sven.Neufeind@ruv.de:
>
>
>
> 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.
How do you render the PDF? From which application?
BR
Maruan
>
> 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/fe00cd3870f6d9ec27fcb5
> 5c89409b420ade0826
>
> In the origin document (before entering the merge step)
> theNeedAppearances 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/fe00cd3870f6d9ec27fcb55c89
> 409b420ade0826/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/fixup/p
> rocessor/AcroFormGenerateAppearancesProcessor.java#L55
>
> Is that an intended behaviour or is that an unintentionally
> sideeffect?
>
>
> Kind regards
>
> Sven Neufeind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: [Bug] (Radio) Buttons can not be printed in a merged PDF
Posted by "sahyoun@fileaffairs.de" <sa...@fileaffairs.de>.
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.Neufeind@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 <TH...@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.Neufeind@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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
AW: [Bug] (Radio) Buttons can not be printed in a merged PDF
Posted by Sv...@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().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 <TH...@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.Neufeind@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
>
Re: [Bug] (Radio) Buttons can not be printed in a merged PDF
Posted by Tilman Hausherr <TH...@t-online.de>.
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.Neufeind@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
>