Attachment damages signature - pdf

I have PDF document.
1) Adobe reader reads document well.
2) I sign document (using pdfbox) and everything is well
3) I try to attach file to original pdf (Code is written in the pdfbox web page - in the cookBook).
4) Adobe reader reads attached document well. everything is well.
5) Now I have document with attachment.
6) I try to sign that document (I mean document with attachment). And I have 2 problem:
First:
when I open document, Adobe reader tells me that signature byte range is invalid.
Second:
when I try to close document (I mean to close adobe reader), Adobe reader tells me that:
Do you want to save changes to "original[with-attachment][signed]" before closing? I didn't find thy this happens.
here is testing files uploaded to the google doc

The cause of your issue is that the process of signing original[with-attachment].pdf creates an incremental update with a cross reference stream while the source file has a cross reference table. When adding incremental updates, the new cross references must be of the same type as the old ones.
It is quite possible that this error is due to the process attaching attach.txt misbehaving a bit, too: it stores the file as a PDF with a cross reference table even though the original was a file with a cross reference stream, but at the same time leaves some elements from the former cross reference dictionary in the trailer of the new file. These left-over elements (which do not belong in a trailer dictionary) probably make your signing process think the source already uses a cross reference stream.
As this change of cross reference style between incremental updates is forbidden, the Adobe Reader tries to fix the document in memory. Such attempts to fix often give rise to unexpected Do you want to save changes to "original[with-attachment][signed]" before closing? warnings.
In the course of fixing the PDF, the whole PDF is rearranged. This obviously causes that signature byte range is invalid.
original.pdf
%PDF-1.3
%âãÏÓ
11 0 obj
<</Linearized 1/L 48987/O 13/E 37674/N 3/T 48682/H [ 480 178]>>
endobj
25 0 obj
<</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Index[11 22]/Info 10 0 R/Length 77/Prev 48683/Root 12 0 R/Size 33/Type/XRef/W[1 2 1]>>stream
hÞbbd``b`jŒ â`–,õ#‚µÄb‰í±#Ä"Q{$¬rÄ‚MLŒ³€,F¬ÄÆK¿ Mi
endstream
endobj
startxref
0
%%EOF
32 0 obj
[.........]
endobj
8 0 obj
<</DecodeParms<</Columns 3/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Info 10 0 R/Length 50/Root 12 0 R/Size 11/Type/XRef/W[1 2 0]>>stream
hÞbb```bœ¬ÅÄÀ°“‰A\š‰H³Îbbà)²'ñ5&F§Û#yF€ xi
endstream
endobj
startxref
116
%%EOF
original[with-attachment].pdf
%PDF-1.3
%öäüß
1 0 obj
[.........]
endobj
xref
0 33
0000000000 65535 f
0000000015 00000 n
[...]
0000049667 00000 n
0000049737 00000 n
trailer
<<
/DecodeParms <<
/Columns 4
/Predictor 12
>>
/Filter /FlateDecode
/ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>]
/Info 5 0 R
/Length 77
/Root 1 0 R
/Size 33
/Type /XRef
/W [1 2 1]
/Index [11 22]
>>
startxref
49755
%%EOF
original[with-attachment][signed].pdf
%PDF-1.3
%öäüß
1 0 obj
[....as above....]
startxref
49755
%%EOF
1 0 obj
[.........]
endobj
37 0 obj
<<
/ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>]
/Info 5 0 R
/Root 1 0 R
/Prev 49755
/Type /XRef
/Size 38
/Filter /FlateDecode
/Index [1 1 6 1 33 4]
/W [1 3 0]
/Length 31
>>
stream
xœcd8ú‘1&ˆ‘áØ.F†ã¾ŒŒ±ù#| VÚ
endstream
endobj
startxref
89569
%%EOF
A side remark
ID management: Your process adding attachments keeps the whole ID. Your signing process drops the whole original ID of the PDF and replaces it with a new one:
original.pdf
/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]
original[with-attachment].pdf
/ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>]
original[signed].pdf
/ID [<A9F7159B1E5D8285A68475689B750214> <A9F7159B1E5D8285A68475689B750214>]
original[with-attachment][signed].pdf
/ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>]
Both approaches are wrong, processes manipulating a PDF and, therefore, creating a new version of it, shall keep the first ID entry and replace only the second one with a unique new one.

Related

PDF that renders in Chrome but not in Acrobat

%PDF-1.7
4 0 obj
<</Type/ObjStm/N 3/First 14/Length 139>>
stream
1 0 2 41 3 76 <</Type/Catalog/Version/1.7/Pages 2 0 R>><</Type/Pages/Kids[3 0 R]/Count 1>><</Type/Page/MediaBox[0 0 200 200]/Parent 2 0 R>>
endstream
endobj
5 0 obj
<<
/Root 1 0 R
/ID[<7F1FE2C507E6DB4CB0787E660F2B0C65><2450E4E8FF5FC84380428886C0DD4C2F>]
/Size 6
/Index[1 5]
/W[1 4 1]
/Type/XRef
/Length 68
/Filter[/ASCIIHexDecode]
>>
stream
020000000400
020000000401
020000000402
010000000A00
01000000E500
endstream
endobj
startxref
229
%%EOF
The PDF above opens in Chrome (or Edge), but in Adobe Acrobat (Reader) it crashes. Ghostscript regards it as fine too. Note that it assumes CRLF for line breaks.
I read the parts of the PDF spec that are relevant for a basic PDF, and it seems that the above syntax follows it. Why doesn't Adobe like it?
Here is a link to the PDF. Notice how it opens in Chrome, but crashes in Adobe Acrobat. (This PDF uses LF for line breaks, and has a Resources dictionary on the page, based on the comments.)
Acrobat has the following 2 quirks, both of which do not follow the specs:
If the XRef Stream has a single filter, an array must not be used. So /Filter[/FlateDecode] won't work, and /Filter/FlateDecode will. This may apply to any Stream Object, not sure.
An XRef Stream must use the FlateDecode filter. ASCIIHexDecode won't work. A predictor is not required.
Here is a link to the above PDF, fixed up for Acrobat.

Insert multiple digital approval signatures without invalidating the previous one

To sign a document we have to place the user signature (converted to a PNG image) on the document then digitally sign this PDF. According to PDF documentation only the first one needs "DocMDP" option. Everything looks fine until I place the second signature (Approval signature). This invalidate the first signature because the document has changed, not the data in signature byterage but due to incremental update (an image has been added).
The questions are:
how to add multiple digital signature (Approval signature) without invalidating the previous one?
How to handle the image signature during incremental update?
Below is an example of PDF structure during incremental updates. (Just an example to show the object inside.)
%PDF-1.7
1 0 obj
<</Type /Pages
/Kids [ 3 0 R]
/Count 1
/MediaBox [0 0 595.28 841.89]
>>
endobj
3 0 obj
<</Type /Page
/Parent 1 0 R
/MediaBox [0 0 595.28 841.89]
/Rotate 0
/Resources 2 0 R
/Group <</Type /Group /S /Transparency /CS /DeviceRGB>>
/Contents [4 0 R 5 0 R] >>
endobj
4 0 obj
<</Length 44>>
stream
BT /F1 24 Tf 175 720 Td (Hello World!)Tj ET
endstream
endobj
5 0 obj
<</Length 93>>
stream
q 15.00 0 0 15.00 80.00 700.00 cm /I1 Do Q
endstream
endobj
2 0 obj
<<
/ProcSet [/PDF /Text /ImageB /ImageC /ImageI]
/Font <<
/F1 7 0 R
>>
/XObject <<
/I1 6 0 R
>>
>>
endobj
7 0 obj
<</Type /Font
/BaseFont /Helvetica
/Subtype /Type1
....
>>
endobj
6 0 obj
<</Type /XObject
/Subtype /Image
/Width 36
/Height 36
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Filter /FlateDecode
/DecodeParms <</Predictor 15 /Colors 3 /BitsPerComponent 8 /Columns 36>>
/SMask 8 0 R
/Length 273>>
stream
[.....]
endstream
endobj
8 0 obj
<</Type /XObject
/Subtype /Image
/Width 36
/Height 36
/ColorSpace /DeviceGray
/BitsPerComponent 8
/Filter /FlateDecode
/DecodeParms <</Predictor 15 /Colors 1 /BitsPerComponent 8 /Columns 36>>
/Length 273>>
stream
[.....]
endstream
endobj
5 0 obj
<<
/Producer (Test Producer)
/CreationDate (D:20180708005634)
>>
endobj
9 0 obj
<<
/Type /Catalog
/Pages 1 0 R
>>
endobj
xref
0 10
0000000000 65535 f
00000000?? 00000 n
0000000??? 00000 n
000000???? 00000 n
000000???? 00000 n
000000???? 00000 n
00000????? 00000 n
00000????? 00000 n
00000????? 00000 n
00000????? 00000 n
trailer
<<
/Size 10
/Root 9 0 R
/Info 5 0 R
>>
startxref
123456
%%EOF
3 0 obj
<</Type /Page
/Parent 1 0 R
/MediaBox [0 0 595.28 841.89]
/Rotate 0
/Resources 2 0 R
/Annots [10 0 R]
/Group <</Type /Group /S /Transparency /CS /DeviceRGB>>
/Contents [4 0 R 5 0 R 10 0 R] >>
endobj
10 0 obj
<</Length 93>>
stream
q 15.00 0 0 15.00 180.00 700.00 cm /I2 Do Q
endstream
endobj
11 0 obj
<< /Type /Annot /Subtype /Widget /Rect [180.000000 700.000000 195.000000 780.000000] /P 3 0 R /F 4 /FT /Sig /T (Test Sig #0) /Ff 0 /V 12 0 R >>
endobj
12 0 obj
<< /Type /Sig /Filter /Adobe.PPKLite /SubFilter /adbe.pkcs7.detached /ByteRange[0 150000 160000 800] /Contents<12321.....0000000000000> /Reference [ << /Type /SigRef /TransformMethod /DocMDP /TransformParams << /Type /TransformParams /P 2 /V /1.2 >> >> ] /Name (Stack Overflow) /Location (USA) /Reason (Testing Signature 0) /ContactInfo (https://stackoverflow.com) /M (D:20180708093628+02'00') >>
endobj
13 0 obj
<</Type /XObject
/Subtype /Image
/Width 36
/Height 36
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Filter /FlateDecode
/DecodeParms <</Predictor 15 /Colors 3 /BitsPerComponent 8 /Columns 36>>
/SMask 14 0 R
/Length 273>>
stream
[.....]
endstream
endobj
14 0 obj
<</Type /XObject
/Subtype /Image
/Width 36
/Height 36
/ColorSpace /DeviceGray
/BitsPerComponent 8
/Filter /FlateDecode
/DecodeParms <</Predictor 15 /Colors 1 /BitsPerComponent 8 /Columns 36>>
/Length 273>>
stream
[.....]
endstream
endobj
9 0 obj
<<
/Type /Catalog
/Pages 1 0 R
/AcroForm << /Fields [ 11 0 R] /NeedAppearances false /SigFlags 3 >> /Perms << /DocMDP 12 0 R >>
>>
endobj
2 0 obj
<<
/ProcSet [/PDF /Text /ImageB /ImageC /ImageI]
/Font <<
/F1 7 0 R
>>
/XObject <<
/I1 6 0 R /I2 13 0 R
>>
>>
endobj
xref
0 1
0000000000 65535 f
2 2
0000000000 00000 n
0000000??? 00000 n
9 6
000000???? 00000 n
00000????? 00000 n
00000????? 00000 n
00000????? 00000 n
00000????? 00000 n
00000????? 00000 n
trailer
<<
/Size 15
/Root 9 0 R
/Info 5 0 R
/Prev 123456
>>
startxref
1234567
%%EOF
3 0 obj
<</Type /Page
/Parent 1 0 R
/MediaBox [0 0 595.28 841.89]
/Rotate 0
/Resources 2 0 R
/Annots [11 0 R 16 0 R]
/Group <</Type /Group /S /Transparency /CS /DeviceRGB>>
/Contents [4 0 R 5 0 R 10 0 R 15 0 R] >>
endobj
15 0 obj
<</Length 93>>
stream
q 15.00 0 0 15.00 280.00 700.00 cm /I3 Do Q
endstream
endobj
16 0 obj
<< /Type /Annot /Subtype /Widget /Rect [280.000000 700.000000 195.000000 780.000000] /P 3 0 R /F 4 /FT /Sig /T (Test Sig #1) /Ff 0 /V 17 0 R >>
endobj
17 0 obj
<< /Type /Sig /Filter /Adobe.PPKLite /SubFilter /adbe.pkcs7.detached /ByteRange[0 150000 160000 800] /Contents<12321.....0000000000000> /Name (Stack Overflow) /Location (USA) /Reason (Testing Signature 0) /ContactInfo (https://stackoverflow.com) /M (D:20180708093628+02'00') >>
endobj
18 0 obj
<</Type /XObject
/Subtype /Image
/Width 36
/Height 36
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Filter /FlateDecode
/DecodeParms <</Predictor 15 /Colors 3 /BitsPerComponent 8 /Columns 36>>
/SMask 14 0 R
/Length 273>>
stream
[.....]
endstream
endobj
19 0 obj
<</Type /XObject
/Subtype /Image
/Width 36
/Height 36
/ColorSpace /DeviceGray
/BitsPerComponent 8
/Filter /FlateDecode
/DecodeParms <</Predictor 15 /Colors 1 /BitsPerComponent 8 /Columns 36>>
/Length 273>>
stream
[.....]
endstream
endobj
9 0 obj
<<
/Type /Catalog
/Pages 1 0 R
/AcroForm << /Fields [11 0 R 16 0 R] /SigFlags 1 >>
>>
endobj
2 0 obj
<<
/ProcSet [/PDF /Text /ImageB /ImageC /ImageI]
/Font <<
/F1 7 0 R
>>
/XObject <<
/I1 6 0 R /I2 13 0 R /I3 18 0 R
>>
>>
endobj
xref
0 1
0000000000 65535 f
2 2
0000000000 00000 n
0000000??? 00000 n
9 1
0000000??? 00000 n
15 5
000000???? 00000 n
00000????? 00000 n
00000????? 00000 n
00000????? 00000 n
00000????? 00000 n
trailer
<<
/Size 20
/Root 9 0 R
/Info 5 0 R
/Prev 1234567
>>
startxref
12345678
%%EOF
UPDATE 09 JUL 2018 - Unsuccessful PDF examples
Additional PDF examples:
Original PDF
https://drive.google.com/open?id=14_raGyJHHJPv2Ze-pWOJ46SargX0JQ0N
First signature - Certified signed
https://drive.google.com/open?id=12aLqKfTczxRAqB3MjklYNBtg5h8DJJ0b
Second signature - Approval signature
https://drive.google.com/open?id=10ghpxuO9gPKRsWcNwsu-ozQH9lth6QVx
Certificate with password "a"
https://drive.google.com/open?id=1eMrjMlVURIVsIo6LLboyii7ewSWoC8xY
These are my tentative. If someone can digitally sign the first file two or more times with an image as signature appearance please share share the results.
UPDATE 11 JUL 2018 - Successful multiple signatures without appearance
In this tentative, during incremental update, I didn't cloned any page (As on previous example) but just updated "/Catalog" object (AcroForm fields). The message "Changes have been made to this document that are permitted by the certifying party" is more than reasonable.
Unsigned PDF example
https://drive.google.com/open?id=1LUQiJMEh73I11NIbL3X8b8LltKseG08a
1st signature example
https://drive.google.com/open?id=150H6SYMPpVf5inZy4uWgqSjOuqOk5hoS
2nd signature example
https://drive.google.com/open?id=1m_6ew4IywNqaOs3uh5o1QLjYKDRDtyNu
3rd signature example
https://drive.google.com/open?id=1IyZQAAwwyaON35qH1xEw_GSsa2RUBaG-
In general
how to add multiple digital signature (Approval signature) without invalidating the previous one?
First of all, obviously the first signature must not be a certification signature with "no changes allowed": Adding a second signature is a change and, therefore, would invalidate the original one.
Furthermore, you have to add the second signature in an incremental update.
Finally, don't add any disallowed changes in the incremental update, cf. this answer.
How this relates to your PDF structures and shared PDF files, you can find in the sections
In your case, original PDF structure
In your case, updated PDF structure
In your case, shared PDF files "Unsuccessful PDF examples"
In your case, shared PDF files "Successful multiple signatures without appearance"
How to handle the image signature during incremental update?
Here the final advice above, don't add any disallowed changes in the incremental updates, is very important. In particular: Don't add a signature visualization to the page content but use the signature widget appearance streams instead.
You find details on this in the sections
How to add signature visualizations
An example of a signature with visualization
How to add signature visualizations
In your files you have merged each of your signature fields with its respective single widget annotation (the objects are both /Type /Annot /Subtype /Widget, i.e. widget annotations, and /FT /Sig, i.e. signature fields) which is pretty common. In such a case no further reference from the field to the widget annotation is necessary. Thus, you merely have to add an appearance to the combined signature field/widget.
First of all,
AP
dictionary
(Optional; PDF 1.2) An appearance dictionary specifying how the annotation shall be presented visually on the page (see 12.5.5, "Appearance streams").
(ISO 32000-2, Table 166 — Entries common to all annotation dictionaries)
Thus, you need to add an appearance dictionary to your signature field and widget objects.
An annotation may define as many as three separate appearances:
The normal appearance shall be used when the annotation is not interacting with the user. This appearance is also used for printing the annotation.
(ISO 32000-2, Section 12.5.5 — Appearance streams)
N
stream or dictionary
(Required) The annotation’s normal appearance.
(ISO 32000-2, Table 170 — Entries in an appearance dictionary)
Thus, your appearance dictionary needs an entry with an /N key.
In case of signature widgets the value is a stream, it is a dictionary of streams only for multi-state annotation, e.g. checkbox form field widgets.
This stream is a form XObject, cf. ISO 32000-2 Section 8.10.2 — Form dictionaries.
An example of a signature with visualization
In the section How to add signature visualizations above I referenced the relevant ISO 32000 sections for the PDF objects to use in a signature visualization. In your comments you asked for more, so I'll show details of an example here.
Let's look into this example file from the PDFBox issue PDFBOX-3198, somewhat pretty-printed.
In there you'll find the signature field and widget combined object
77 0 obj
<<
/FT /Sig
/Type /Annot
/Subtype /Widget
/F 132
/T (Signature1)
/V 82 0 R
/P 13 0 R
/Rect [0.0 792.0 100.0 842.0]
/AP <<
/N 83 0 R
>>
>>
Your signatures use most of these entries, too, except the AP entry. This is the appearance dictionary and it contains a single entry with the N key. This references the normal appearance of the signature in object 83:
83 0 obj
<<
/Length 171
/Type /XObject
/Subtype /Form
/Resources <<
/XObject <<
/Im1 84 0 R
>>
/Font 85 0 R
>>
/BBox [0.0 0.0 100.0 50.0]
/FormType 1
>>
stream
q
0.25 0 0 0.25 0 0 cm
q
200 0 0 142 0 0 cm
/Im1 Do
Q
Q
BT
/F1 10 Tf
10 35 Td
15 TL
(\(Signature line 1\)) Tj
T*
(\(Signature line 2\)) Tj
T*
(\(Signature line 3\)) Tj
ET
endstream
endobj
This appearance stream is a form XObject of form type 1 (cf. its Type, Subtype, and FormType entries) with its own resources, an image XObject Im1 in object 84 and fonts in object 85 (cf. its Resources entry).
It furthermore has a boundary box (cf. its BBox entry) which defines the area in which the instructions in its stream can draw an appearance. This area with everything drawn there will be displayed by a PDF viewer in the page area defined by the Rect entry of the signature widget annotation, see above.
In the stream you see instructions to draw the bitmap image resource and three lines of text.
There is nothing special about its font resources in object 85, either:
85 0 obj
<<
/F1 86 0 R
>>
endobj
86 0 obj
<<
/Type /Font
/Subtype /Type1
/BaseFont /Helvetica-Bold
/Encoding /WinAnsiEncoding
>>
Beware, if you happen to have to deal with documents with page rotation, be sure to
either not set the NoRotate annotation flag of the signature widget (the 24 summand of the F value) but add a rotation to the form XObject or its content
or set the NoRotate annotation flag and consider the effects thereof in your calculation of the annotation Rect values,
cf. this answer for details.
In your case, original PDF structure
In your case you use incremental updates and have a certification signature with the required changes allowed. Other than that, though, the PDF is utterly broken.
There are weirdnesses already in the incremental update with the first signature:
You add a content stream (object 10 0) to the page as content stream. Ok. But you also reference this content stream in the Annots array of your page. This does not make sense, a naked content stream is not an annotation.
Probably the image shown in this content stream is meant as signature visualization. In that case, though, both changes above would be completely wrong, a signature visualization belongs into an appearance xobject of the signature widget, not into the page content.
The incremental update for the second signature is completely weird,
in the resources of the page you
add an image xobject to the xobject resources (which may already be counted as disallowed) and
set the previously already existing font F1 to point to the signature field 16 0 (which clearly is destructive nonsense);
in the AcroForm dictionary you
reference object 15 0 as new field, but 15 0 only is a content stream (destructive nonsense),
reduce the SigFlags value from 3 to 1 (very inappropriate for a signed document), and
drop the Perms entry (something the document MDP signature won't find funny).
Furthermore, the cross references obviously are broken. By design when copying & pasting here? By error already in the original file? I cannot tell.
So the bottom line is that in particular the last incremental update is completely broken and cannot serve as a sensible base for a question about "Inserting multiple digital approval signatures without invalidating the previous one" because unrelated basics already are wrong.
In your case, updated PDF structure
You edited the PDF structure, and now it makes more sense. At least you don't reference the wrong objects from resources or field lists anymore, except in one case.
These obvious issues remain:
As already mentioned you still reference one inappropriate object, in the revision with the certification signature the Page dictionary still references object 10 in its Annots array, but object 10 is but a content stream, no annotation. object 11, the signature field and widget, is the object you should reference.
Actually in the final revision, the revision of the approval signature, you have corrected it. But only correcting this in the newest revision but not in the first signed revision results in a change between revisions which may or may not be allowed...
You still inappropriately change the AcroForm dictionary contents in your final revision, you reduce the SigFlags value from 3 to 1 and drop the Perms entry.
The former change is a bad idea because you so signal to upcoming PDF processors that they do not need to apply changes in incremental updates, i.e. you beg them to damage your signatures.
The latter change is not immediately a problem but a very sensitive signature validator may consider this a suspicious change.
Now your final incremental update also changes the page content and adds a new content stream to it which draws an image.
Changing page content of a signed document is disallowed, cf. my answer already referenced above in the general section. Thus, even if the other changes don't cause Adobe Reader to claim an invalidated signature, this one will.
In a comment to your question you actually already admit this change:
Yes, the images are placed into the page because I don't know how to use as signature visualization to belong into an appearance xobject of the signature widget.
On this issue have a look at the section "How to add signature visualizations" of my answer above.
In your case, shared PDF files "Unsuccessful PDF examples"
In the complete PDFs you shared the situation is similar to that in the updated PDF structure discussed above. There are some minor differences, though, and due to the completeness of the file additional issues come to light.
Unused Document Information Dictionaries - in each revision you create a new Document Information Dictionary but your trailers keep referencing the dictionary of the initial revision. Harmless but surely not intended this way.
Empty ToUnicode maps - each of your fonts has a ToUnicode entry which points to an empty stream. This is invalid: If there is a ToUnicode entry in a font, its value MUST be a stream containing a CMap file that maps character codes to Unicode values, and the common expectation is that the mapping is complete as far as character codes actually used in the document are concerned.
Duplicate font resources - In the incremental updates you add fonts to the page resources have the same resource name as already existing fonts in the same resources, i.e. you create duplicate entries for these names. As multiple entries in the same dictionary shall not have the same key, this makes your PDF invalid.
When applying your approval signature you still drop the Perms entry with the reference to the certification signature from the AcroForm dictionary. This is probably harmless as a validator will find that signature in a signature form field anyways, but a very sensitive validator might report this as suspicious change anyways.
Changes to the page content - just like before (as discussed under updated PDF structure) you add a signature visualization to the page content. As before it is harmless for the first signature but it is a disallowed change in follow-up signatures.
Changes to the page resources - you add new image XObjects and new fonts the the page resources.
If they were not used in the page content, this is probably harmless but that means counting on validators checking for usage of added resources. Validators that don't check for usage will surely consider this a disallowed change.
In your case, though, the added resources are used, so they definitively are part of a disallowed change.
Thus, Adobe completely correctly reports that there have been changes made to this document that invalidate the certification signature and displays that certification signature as invalid. If you don't want this, stop adding disallowed changes, in particular stop changing the page content stream. Instead put signature visualizations into signature widget appearance streams as described above.
Furthermore, be a bit more attentive and don't create non-conforming PDF structures.
In your case, shared PDF files "Successful multiple signatures without appearance"
By signing without visualizations you indeed got rid of items 3, 5, and 6. Furthermore no unused document information dictionaries are present anymore, resolving item 1.
You got rid of item 4 by not adding a Perms dictionary to the catalog of the revision with the certification signature to start with. While this of course is possible, I'd recommend you also make sure that your code for adding further approval signatures does not remove Perms dictionaries.
Item 2 remains, your fonts still have empty ToUnicode values. While not relevant for the issue at hand, this is invalid and it is likely to disturb some text extraction implementations.
Other than that you
switched the DocMDP transform P value from 2 to 3; unless you really need to allow arbitrary annotation creation, deletion, and modification, I'd recommend against this because annotations can substantially change the appearance of a document;
use RSA with the PKCS#1 v.1.5 signature scheme for signing; in a new signing application without a requirement for backward compatibility I'd instead recommend using the RSASSA-PSS signature scheme as defined in PKCS#1 since version 2.1 because acceptance of the PKCS#1 v.1.5 scheme is likely to dwindle in the early 2020s;
but these are items to fine-tune your code once all actual errors are wiped out.
I found this conversation very interesting and I wish I understood it well enough to implement the ideas discussed, as h20dev was able to do.
MKL is very knowledgeable about PDFs and digital signatures, as I have read a lot of his replies while researching this subject.
For anyone who is still struggling to do Multiple Digital Signatures on PDFs with incremental updates, check out this github which I have had great success using to do this task:
https://github.com/vbuch/node-signpdf

Generated PDF displaying empty pages

I'm writing a PDF generator for an embedded system and i can't seem to get it to render. Here's what i have so far http://pastebin.com/20DQiGfb.
Neither ghostscript, nor RUPS is showing any syntax errors, and every PDF viewer i checked this on displays blank pages. I'v verified the syntax, offsets, structure to be fine. I just don't get it.
Maybe someone can suggest another tool i can try ? Maybe one that would let me inspect the visual elements ?
EDIT: adding the full file for download https://drive.google.com/file/d/0B8ljtiq-2gIJcTBFR2tjRGxVOFk/view?usp=sharing
EDIT2: Acrobat/Preflight also found no errors
These are your Page dictionaries:
7 0 obj
<< /Type /Page
/Parent 9 0 R
/Resources 2 0 R
/Content 3 0 R
/MediaBox [0 0 612 792]
>>
endobj
8 0 obj
<< /Type /Page
/Parent 9 0 R
/Resources 2 0 R
/Content 5 0 R
/MediaBox [0 0 612 792]
>>
endobj
But the correct key for the content stream is Contents!
Contents stream or array (Optional) A content stream (see 7.8.2, "Content Streams") that shall describe the contents of this page. If this entry is absent, the page shall be empty.
(Table 30 – Entries in a page object - ISO 32000-1)
After adding the missing s characters I see:
and

PostScript PDF (1.7), manually writing code

I'm trying to manually write a simple PDF file that contains a title, some text, and an image. I found one example of a manually written "Hello world" and managed to change some things, but I cant get it working for another text object. I have looked for help on the internet but with no luck, I guess not many people write their own PDF files.
This is what I have so far:
%PDF-1.7
1 0 obj % entry point
<<
/Type /Catalog
/Pages 2 0 R
>>
endobj
2 0 obj
<<
/Type /Pages
/MediaBox [ 0 0 200 200 ]
/Count 1
/Kids [ 3 0 R ]
>>
endobj
3 0 obj
<<
/Type /Page
/Parent 2 0 R
/Resources <<
/Font <<
/F1 4 0 R
>>
>>
/Contents 4 0 R
>>
endobj
4 0 obj % page content
<<
/Length 20
>>
stream
BT
80 180 TD
/F1 14 Tf
(PDF) Tj
ET
endstream
endobj
5 0 obj % page content
<<
/Length 20
>>
stream
BT
50 70 TD
/F1 14 Tf
(this is a pdf) Tj
ET
endstream
endobj
trailer
<<
/Size 6
/Root 1 0 R
>>
startxref
492
%%EOF
I have tried adding another text object with "this is a pdf" text but it wont show up, I don't know what could be wrong, I tried changing a few things but with no luck. The image part I don't have it either, so some help with that would be nice.
This is a wiki about the "hello world" pdf I found:
http://www.gnupdf.org/Introduction_to_PDF
Adobe offers some explanation on how the pdf works but I cant find anything that would fix my problem:
http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf
This is not a valid PDF. If Acrobat opens it at all it's because it's given up on the xref table and done a full scan of the file, but your PDF is invalid. 4 0 obj is not a font, as you specified, and 5 0 obj is not accessed from anywhere.
PDF specification requires an xref table which points to the exact position in the file for each object. You can't realistically write this by hand unless you intend to manually update the entire xref table every time you add or remove even 1 byte from the file.
You can write a PDF from scratch like this from code easily enough but it will not work to just open a PDF in notepad and start changing things because the index (xref) immediately becomes corrupt.
I'd also advise against putting comments throughout the file unless the comments start on new lines. Otherwise some PDF parsers will get confused as this is generally not expected. Usually PDF files do not contain comments (with the exception of the second line, which is recommended by Adobe to be a comment of some non-ASCII characters so FTP recognizes the file as binary) seeing as they are virtually impossible to write manually anyway.
http://www.adobe.com/devnet/pdf/pdf_reference.html
A few years ago, I wrote a book which covers exactly this sort of thing:
http://www.amazon.com/PDF-Explained-John-Whitington/dp/1449310028/
No free online version, I'm afraid. You can get all the same information from Adobe's own documentation, which is free, but it's a rather long document!

Set PDF to print with no scaling

I am generating a PDF (using fpdf) and I am wondering if there is a way to set the document's properties to to default to print with no scaling.
So when you select print from the print dialogue menu, scaling is set to none. I'm trying to determine if this is a user setting or something I can control in the creation of the PDF.
Thanks in advance.
I've done it adding to the method _putcatalog() the following:
$this->_out('/ViewerPreferences [/PrintScaling/None]');
After the line:
$this->_out('/Type /Catalog');
Implementing a method is just fast and easy...
Print-scaling can be turned off for invividual PDF files using Adobe Acrobat, by going to File -> Preferences -> Advanced -> Page scaling. (You can try this using the trial version of Acrobat.)
As for achieving this in code, I've tried and failed to make it work, but the critical difference in the files seems to be:
10 0 obj
<</Metadata 2 0 R/Outlines 6 0 R/Pages 7 0 R/Type/Catalog/ViewerPreferences<</PrintScaling/None>>>>
endobj
for non-scaling PDFs, compared to
10 0 obj
<</Metadata 2 0 R/Outlines 6 0 R/Pages 7 0 R/Type/Catalog>>
endobj
for those that use the default shrink-to-fit option.
For me changing the FPDF Catalog method _putcatalog() and adding
$this->_out('/ViewerPreferences [/PrintScaling/None]');
wasn't accomplishing the goal so I looked at the code produced by a Acrobate XI PDF and found some more verbage. Adding the following code
$this->_out('/ViewerPreferences<</Duplex/Simplex/Enforce[/PrintScaling]/PrintScaling/None>>');
created a PDF that no longer defaulted to scaling and instead only gave the option to print Actual Size which was what was desired.
Scaling is controlled by the PDF application - it is not set in the file.
well i'm not sure if you mean somethink like this:
http://www.fpdf.org/en/doc/setdisplaymode.htm
or no "scaling" for images?
$im2 = pdf_open_image_file($dokument, 'jpeg', 'example.jpg');
pdf_place_image($dokument, $im2, 395, 655, 1.0); /* 1.0 = qualiti/scaling - 1.0 is original .../*
pdf_close_image($dokument, $im2);
I ran into the same problem.
I have several PDFs where the content of the PDF, that is text and images, go very near the PDFs border but still the print dialogue Preview/Acrobat suggests printing it in 100% scaling, thus cutting off the contents which aren't printable because of the printers natural margins.
Creating any PDF in Pages for example results in a PDF which is printed in 100% scaling by default.
However if I create a PDF using TCPDF which is related to FPDF than the printer dialog suggests to scale it in order to fit the page.
My suspicion is that the way the PDF is created is different. I suspect that Pages and other tools create separate layers and they are then handeled differently, possibly by a flag or something.
I compared the readable parts of my two PDF-Files and did come accross some differences, especially on how the documents begin. My knowledge of the PDF-Sources is, however very limited, so I can only guess what needs to change.
Is there a PDF-Reference where it is stated how to control the printable objects/areas?
Here the content of a minimal PDF which will be printed without scaling:
%PDF-1.4
1 0 obj
<< /Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
>>
endobj
2 0 obj
<< /Type /Outlines
/Count 0
>>
endobj
3 0 obj
<< /Type /Pages
/Kids [4 0 R]
/Count 1
>>
endobj
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [0 0 595 842]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R
/Font << /F1 7 0 R >>
>>
>>
endobj
5 0 obj
<< /Length 73 >>
stream
BT
/F1 24 Tf
100 100 Td
(Hello World) Tj
ET
endstream
endobj
6 0 obj
[ /PDF /Text ]
endobj
7 0 obj
<< /Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /MacRomanEncoding
>>
endobj
xref
0 8
0000000000 65535 f
0000000009 00000 n
0000000074 00000 n
0000000120 00000 n
0000000179 00000 n
0000000364 00000 n
0000000466 00000 n
0000000496 00000 n
trailer
<< /Size 8
/Root 1 0 R
>>
startxref
625
%%EOF
Ok, I think I got it.
Try this: open your TCPDF-created PDF and remove all occurenecs of viewerpreferences and any box-statements other than the MediaBox... doing so finally resulted in a print-default-scaling-free PDF :)
seams like those additional infos -intended for professional printing- only confuse the common pdf-viewer instead of helping with anything :)
Goto tcpdf.php and change line 8529 in method _putpages as follows
change
$boxes = array('MediaBox', 'CropBox', 'BleedBox', 'TrimBox', 'ArtBox');
into
$boxes = array('MediaBox');
In my PDF-output this instantly removed the scaling problem :)