search

vizicsaba89 / pdf-signer

sign pdf documents
MIT License
37 stars 33 forks source link

Acrobat Error: Unrecognized object name. #17

Open NoahCardoza opened 3 years ago

NoahCardoza commented 3 years ago

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.

pankucsi commented 3 years ago

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.

pankucsi commented 3 years ago

I published the newest version. Can you try it out again or provide a repository please ? Maybe it has been resolved already.

NoahCardoza commented 3 years ago

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.

pankucsi commented 3 years ago

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.

vbuch commented 3 years ago

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.

vizicsaba89 commented 3 years ago

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.

darktohka commented 3 years ago

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.

lutfi-haslab commented 3 months ago

where to add await pdfDoc.save({ useObjectStreams: false });?