pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Nibali <rnib...@gmail.com>
Subject Re: Injecting Javascript into a PDF with form fields
Date Wed, 19 Aug 2015 18:40:52 GMT
Hi Maruan

On Wed, Aug 19, 2015 at 8:18 AM, Maruan Sahyoun <sahyoun@fileaffairs.de>

> Hi,
> > Am 18.08.2015 um 20:29 schrieb Roberto Nibali <rnibali@gmail.com>:
> >
> > Hello
> >
> > I'm trying to chase down a weird feature of the Acrobat Reader, which has
> > been puzzling me for days now: whenever I inject javascript into the
> > document open event, some form fields of certain PDFs I'm working with
> get
> > *renamed* automatically by Acrobat. If I do not inject the Javascript
> code,
> > the field names remain the same. Basically, the relevant code is like
> > follows:
> >
> > @Test
> > public void SimpleTest() throws IOException {
> >    PDDocument tplDoc;
> >    String tplDocName = "./cctemp2.pdf";
> >    String outDocName = "./ccmig2.pdf";
> >
> >    tplDoc = PDDocument.load(new File(tplDocName));
> >    String ac = "app.alert({cMsg: 'It seems we have injected some
> > JavaScript', cTitle: 'Information', nIcon: 3});";
> >    PDAction action = new PDActionJavaScript(ac);
> >    tplDoc.getDocumentCatalog().setOpenAction(action);
> >    tplDoc.save(outDocName);
> >    tplDoc.close();
> > }
> >
> > *Question*: Does anybody here have a good understanding of the PDF
> > "standard" to explain to me under which circumstances this is happening?
> Or
> > is it a peculiarity of Acrobat? Has anybody ever encountered this before?
> > Strangely enough, it only happens with some PDFs, others (which are
> almost
> > identical) are left alone. How would I be able to debug this?
> would you have a PDF where it works and one where it doesn't?

This will be very difficult. The last time we synthesized the PDFs to a
degree where I could post them publicly, it took a long time and the
resulting PDFs do not exhibit this issue.

Today, we've spent some hours with the PDFDebugger to figure out
differences between the two PDFs (the one that does not show this weird
behaviour and one that does), however we couldn't really spot something
that would have triggered Acrobat Reader to behave like that.

We then found out that when you edit the PDF in Acrobat Pro DC and rename
the form field to a different name (still in the same naming tree), rename
it back to the original name, the issue does not show up anymore. This is a
totally weird but  acceptable solution for us, since we only have to
manually modify 16 template PDFs. The peculiar thing happens when you then
save the PDF: Acrobat reorders the kids of the form entry dictionary,
according to PDFDebugger. It seems as if the order combined with a totally
unrelated doc/open JS injection had an influence on whether or not Acrobat
Reader subsequently decides to rename certain form fields.

Adobe truly perfectioned the art of creating markets and making money!!!

Thanks for your reply anyway. If we manage to deliver the solution
tomorrow, I'm certain that over time we'll find some hours to synthesize
the PDFs to a degree usable for the project. It seems that our PDFs
triggered quite some issues over the past couple of months :).

Best regards

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message