pdf-signer
pdf-signer copied to clipboard
Acrobat Error: Unrecognized object name.
When using the shouldAnnotationAppearOnFirstPage
this error occurs.
I also tested with the throw_out_pdfmockkit branch using annotationOnPage
the same error occurs. Interestingly enough, it seems to inclusively corrupt all the following pages.
E.G.
If I set annotationOnPage: 0
all the pages will be blank and throw said error. But If I set annotationOnPage: 1
the first page will display but all following pages will be corrupted.
Okay, i will merge the branches in this week, and after that i will give a look, but in the meantime if you find the bug please feel free to open a PR.
I published the newest version. Can you try it out again or provide a repository please ? Maybe it has been resolved already.
Sorry, I could have sworn I edited the issue with an example repo. Here it is. I did a little digging here https://github.com/vbuch/node-signpdf/issues/104 seeing as I want to sign an existing \Sig \Widget
.
RE: @vbuch
https://github.com/vbuch/node-signpdf#append-a-signature-placeholder
What's needed is a Sig element and a Widget that is also linked in a Form. The form needs to be referenced in the root descriptor of the PDF as well. A (hopefully) readable sample is available in the helpers. Note the Contents descriptor of the Sig where zeros are placed that will later be replaced with the actual signature.
That's how it is in a PDF 1.3. Where is the root descriptor of latter version, i have no clue.
I wonder if ^ could be the problem? However it works on the last page so I'm not sure.
Yes you did, but it was an another issue and you have closed it :D .
And you was right. Unfortunatly in the moment we cant parse the newer pdf formatum.
When we have started working with the PDF signing, we havent known it has a newer syntax what is working with byte streams. Am I right @vizicsaba89 ?
I thought this issue is completly an another bug from that.
For future explanation @vbuch was right with the root descriptor. According to my memories We are parsing the structure from that and we are modifying the trailer if we are appending new elements into the PDF.
Basically that's how PDFs worked up until 1.3. You always read from the end up. This allows for newer trailers to be added that override previous ones enabling incremenatl updates. node-signpdf's main purpose was to show how signing is done. It does that. PRs working with higher versions of PDF are more than welcome.
Yes you did, but it was an another issue and you have closed it :D .
And you was right. Unfortunatly in the moment we cant parse the newer pdf formatum.
When we have started working with the PDF signing, we havent known it has a newer syntax what is working with byte streams. Am I right @vizicsaba89 ?
I thought this issue is completly an another bug from that.
For future explanation @vbuch was right with the root descriptor. According to my memories We are parsing the structure from that and we are modifying the trailer if we are appending new elements into the PDF.
Yeah, @pankucsi is right, this new pdf format is totally unfamiliar to us too, and the pdf-signer is not compatible with it at the moment, so we need further investigation to implement a working solution.
I've been wrestling with this problem since yesterday, and I've got something to add regarding this issue.
I tried to use pdf-kit
to edit (and create) PDFs that I needed to sign afterwards using pdf-signer
. Of course, pdf-kit
creates files that are incompatible with pdf-signer
.
As mentioned before, pdf-signer
has its own PDF parser that relies on the existence of a PDF trailer
and an xref
table. After closely examining the pdf-kit
source code, I realized that the trailer (AND xref table!) is still being generated. It's just packaged into a deflate stream (stream
/endstream
) at the end of the PDF.
But this behavior can be changed, using an (undocumented) save option called useObjectStreams
. If useObjectStreams
is set to false
, then pdf-kit
will generate PDFs with a raw trailer and xref table.
So, for anyone trying to sign PDFs that were created by pdf-kit
using pdf-signer
:
await pdfDoc.save({ useObjectStreams: false });
will do the trick.
where to add await pdfDoc.save({ useObjectStreams: false });?