Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
pdftk_usage_et_exemple [2025/01/27 11:16] – [EXAMPLES] frater | pdftk_usage_et_exemple [2025/06/30 13:51] (Version actuelle) – [[drop_xfa]] frater | ||
---|---|---|---|
Ligne 52: | Ligne 52: | ||
==== SYNOPSIS ==== | ==== SYNOPSIS ==== | ||
- | <code> | + | <cli bash> |
- | pdftk <input PDF files | - | PROMPT> | + | frater@supremae: |
[ input_pw <input PDF owner passwords | PROMPT> ] | [ input_pw <input PDF owner passwords | PROMPT> ] | ||
[ < | [ < | ||
Ligne 66: | Ligne 66: | ||
[ replacement_font <font name> ] | [ replacement_font <font name> ] | ||
[ verbose ] [ dont_ask | do_ask ] | [ verbose ] [ dont_ask | do_ask ] | ||
- | </code> | + | </cli> |
| | ||
< | < | ||
- | [ cat | shuffle | + | |
+ | < | ||
+ | cat | ||
+ | shuffle | ||
+ | burst | ||
+ | rotate | ||
+ | generate_fdf | ||
+ | fill_form | ||
+ | background | ||
+ | multibackground | ||
+ | stamp | ||
+ | multistamp | ||
+ | dump_data | ||
+ | dump_data_utf8 | ||
+ | dump_data_fields | ||
+ | dump_data_fields_utf8 | ||
+ | dump_data_annots | ||
+ | update_info | ||
+ | update_info_utf8 | ||
+ | attach_files | ||
+ | unpack_files | ||
+ | </ | ||
For Complete Help: pdftk --help | For Complete Help: pdftk --help | ||
Ligne 95: | Ligne 116: | ||
A summary of options is included below. | A summary of options is included below. | ||
- | **--help, -h ** | + | === --help, -h === |
Show this summary of options. | Show this summary of options. | ||
- | **<input PDF files | - | PROMPT>** | + | === <input PDF files | - | PROMPT> |
A list of the input PDF files. If you plan to combine these PDFs (without using handles) then list files in the order you want them combined. | A list of the input PDF files. If you plan to combine these PDFs (without using handles) then list files in the order you want them combined. | ||
Ligne 105: | Ligne 126: | ||
//<input PDF handle> | //<input PDF handle> | ||
- | | + | For example: |
- | | + | <code> |
- | Input PDF owner passwords, if necessary, are associated with files by using their handles: | + | A=input1.pdf QT=input2.pdf M=input3.pdf |
+ | </ | ||
- | | + | === input_pw |
+ | |||
+ | Input PDF owner passwords, if necessary, are associated with files by using their handles: | ||
- | If handles are not given, then passwords are associated with input files by order. | + | < |
+ | <input PDF handle> | ||
+ | </ | ||
- | Most pdftk features require that encrypted input PDF are accompanied by the ~owner~ password. If the input PDF has no owner password, then the user password must be given, instead. If the input PDF has no passwords, then no password should be given. | + | If handles |
- | When running in do_ask mode, pdftk will prompt you for a password | + | Most pdftk features require that encrypted input PDF are accompanied by the ~owner~ |
- | | + | When running in do_ask mode, pdftk will prompt you for a password if the supplied password is incorrect or none was given. |
- | Available operations are: cat, shuffle, burst, rotate, generate_fdf, | + | |
- | If this optional argument is omitted, then pdftk runs in ' | + | === < |
+ | Available operations are: //cat//, //shuffle//, //burst//, //rotate//, // | ||
- | cat [<page ranges> | + | Some operations takes additional arguments, described below. |
- | | + | |
- | <input PDF handle> | + | If this optional argument is omitted, then pdftk runs in '// |
+ | |||
+ | === cat [<page ranges>] === | ||
+ | Assembles (catenates) pages from input PDFs to create a new PDF. Use cat to merge PDF pages or to split PDF pages from documents. You can also use it to rotate PDF pages. Page order in the new PDF is specified by the order of the given page ranges. Page ranges are described like this: | ||
+ | |||
+ | < | ||
+ | <input PDF handle> | ||
+ | </ | ||
+ | |||
+ | Where the handle identifies one of the input PDF files, and the beginning and ending page numbers are one-based references to pages in the PDF file. The qualifier can be even, odd, or ~, and the page rotation can be north, south, east, west, left, right, or down. | ||
+ | |||
+ | If a PDF handle is given but no pages are specified, then the entire PDF is used. If no pages are specified for any of the input PDFs, then the input PDFs' bookmarks are also merged and included in the output. | ||
+ | |||
+ | If the handle is omitted from the page range, then the pages are taken from the first input PDF. | ||
+ | |||
+ | The even qualifier causes pdftk to use only the even-numbered PDF pages, so 1-6even yields pages 2, 4 and 6 in that order. 6-1even yields pages 6, 4 and 2 in that order. | ||
+ | |||
+ | The odd qualifier works similarly to the even. | ||
+ | |||
+ | Pages can be subtracted from a page range using the ~ qualifier followed by a page range. For instance, 1-20~5-6 and 1-20~5~6 are equivalent to 1-4 7-20, and ~5 yields all pages except page 5. Depending on your shell, you may need to quote this argument because of the ~ at the beginning. | ||
+ | |||
+ | The page rotation setting can cause pdftk to rotate pages and documents. Each option sets the page rotation as follows (in degrees): north: 0, east: 90, south: 180, west: 270, left: -90, right: +90, down: +180. left, right, and down make relative adjustments to a page's rotation. | ||
+ | |||
+ | If no arguments are passed to cat, then pdftk combines all input PDFs in the order they were given to create the output. | ||
+ | |||
+ | <WRAP center round info> | ||
+ | * <end page number> may be less than <begin page number> | ||
+ | * The keyword end may be used to reference the final page of a document instead of a page number. | ||
+ | * Reference a single page by omitting the ending page number. | ||
+ | * The handle may be used alone to represent the entire PDF document, e.g., B1-end is the same as B. | ||
+ | * You can reference page numbers in reverse order by prefixing them with the letter r. For example, page r1 is the last page of the document, r2 is the next-to-last page of the document, and rend is the first page of the document. You can use this prefix in ranges, too, for example r3-r1 is the last three pages of a PDF. | ||
+ | </ | ||
+ | |||
+ | Page Range Examples without Handles: | ||
+ | |||
+ | * 1\-endeast - rotate entire document 90 degrees | ||
+ | * 5 11 20 - take single pages from input PDF | ||
+ | * 5-25oddwest - take odd pages in range, rotate 90 degrees | ||
+ | * 6-1 - reverse pages in range from input PDF | ||
+ | |||
+ | Page Range Examples Using Handles: | ||
+ | |||
+ | * A1-21 - take range from in1.pdf | ||
+ | * Bend-1odd - take all odd pages from in2.pdf in reverse order | ||
+ | * A72 - take a single page from in1.pdf | ||
+ | * A1-21 Beven A72 - assemble pages from both in1.pdf and in2.pdf | ||
+ | * Awest - rotate entire in1.pdf document 90 degrees | ||
+ | * B - use all of in2.pdf | ||
+ | * A2-30evenleft - take the even pages from the range, remove 90 degrees from each page's rotation | ||
+ | * A A - catenate in1.pdf with in1.pdf | ||
+ | * Aevenwest Aoddeast - apply rotations to even pages, odd pages from in1.pdf | ||
+ | * Awest Bwest Bdown - catenate rotated documents | ||
+ | |||
+ | |||
+ | |||
+ | === shuffle [<page ranges>] === | ||
+ | Collates pages from input PDFs to create a new PDF. | ||
+ | Works like the cat operation except that it takes one page at a time from each page range to assemble the output PDF. | ||
+ | If one range runs out of pages, it continues with the remaining ranges. | ||
+ | Ranges can use all of the features described above for cat, like reverse page ranges, multiple ranges from a single PDF, and page rotation. | ||
+ | This feature was designed to help collate PDF pages after scanning paper documents. | ||
+ | |||
+ | === burst === | ||
+ | |||
+ | Splits a single input PDF document into individual pages. | ||
+ | |||
+ | Also creates a report named doc_data.txt which is the same as the output from dump_data. | ||
+ | The output section can contain a printf-styled format string to name these pages. | ||
+ | For example, if you want pages named page_01.pdf, | ||
+ | Encryption can be applied to the output by appending output options such as owner_pw, e.g.: | ||
+ | |||
+ | <cli bash> | ||
+ | frater@supremae: | ||
+ | </ | ||
+ | === rotate [<page ranges>] === | ||
+ | |||
+ | Takes a single input PDF and rotates just the specified pages. All other pages remain unchanged. | ||
+ | Specify the pages to rotate using the same notation as you would with cat, except you omit the pages that you aren't rotating: | ||
+ | |||
+ | |||
+ | < | ||
+ | [<begin page number> | ||
+ | </ | ||
- | Where the handle identifies one of the input PDF files, and the beginning and ending page numbers are one-based references to pages in the PDF file. The qualifier can be even, odd, or ~, and the page rotation can be north, south, east, west, left, right, or down. | + | The qualifier can be even or odd, and the page rotation can be //north//, //south//, //east//, //west//, //left//, //right//, or //down//. |
- | If a PDF handle is given but no pages are specified, then the entire PDF is used. If no pages are specified for any of the input PDFs, then the input PDFs' bookmarks are also merged and included | + | Each option sets the page rotation as follows (in degrees): |
- | If the handle is omitted from the page range, then the pages are taken from the first input PDF. | + | * north: 0, |
+ | * east: 90, | ||
+ | * south: 180, | ||
+ | * west: 270, | ||
+ | * left: -90, | ||
+ | * right: +90, | ||
+ | * down: +180. | ||
- | The even qualifier causes pdftk to use only the even-numbered PDF pages, so 1-6even yields pages 2, 4 and 6 in that order. 6-1even yields pages 6, 4 and 2 in that order. | + | //left//, //right//, and //down// make relative adjustments to a page's rotation. |
- | The odd qualifier works similarly to the even. | + | The given order of the pages doesn' |
- | Pages can be subtracted from a page range using the ~ qualifier followed by a page range. For instance, 1-20~5-6 and 1-20~5~6 are equivalent to 1-4 7-20, and ~5 yields all pages except page 5. Depending on your shell, you may need to quote this argument because of the ~ at the beginning. | + | === generate_fdf === |
- | The page rotation setting can cause pdftk to rotate pages and | + | Reads a single input PDF file and generates an FDF file suitable for fill_form out of it to the given output filename or (if no output is given) to stdout. Does not create |
- | | + | |
- | | + | |
- | -90, right: +90, down: +180. left, right, and down make rela- | + | |
- | tive adjustments to a page's rotation. | + | |
- | If no arguments are passed to cat, then pdftk combines all | + | === fill_form <FDF data filename | XFDF data filename | - | PROMPT> === |
- | | + | |
+ | Fills the single | ||
- | | + | <cli> |
- | | + | frater@host: |
- | * The keyword end may be used to reference the final page of | + | </ |
- | a document instead of a page number. | + | |
- | * Reference a single page by omitting the ending page number. | + | |
- | * The handle may be used alone to represent the entire PDF | + | |
- | | + | |
- | * You can reference page numbers in reverse order by prefix- | + | |
- | ing them with the letter r. For example, page r1 is the last | + | |
- | page of the document, r2 is the next-to-last page of the doc- | + | |
- | | + | |
- | use this prefix in ranges, too, for example r3-r1 is the last | + | |
- | three pages of a PDF. | + | |
- | Page Range Examples without Handles: | ||
- | | ||
- | 5 11 20 - take single pages from input PDF | ||
- | | ||
- | 6-1 - reverse pages in range from input PDF | ||
- | Page Range Examples Using Handles: | + | If the input FDF file includes Rich Text formatted data in addition to plain text, then the Rich Text data is packed into the form fields as well as the plain text. |
- | Say A=in1.pdf B=in2.pdf, then: | + | Pdftk also sets a flag that cues Reader/ |
- | A1-21 - take range from in1.pdf | + | So when the user opens the PDF, the viewer will create the Rich Text appearance on the spot. |
- | Bend-1odd - take all odd pages from in2.pdf in reverse order | + | If the user' |
- | A72 - take a single page from in1.pdf | + | If you flatten this form before Acrobat has a chance |
- | A1-21 Beven A72 - assemble pages from both in1.pdf and | + | |
- | | + | |
- | Awest - rotate entire in1.pdf document 90 degrees | + | |
- | B - use all of in2.pdf | + | |
- | | + | |
- | degrees from each page' | + | |
- | A A - catenate in1.pdf with in1.pdf | + | |
- | Aevenwest Aoddeast - apply rotations | + | |
- | from in1.pdf | + | |
- | Awest Bwest Bdown - catenate rotated documents | + | |
- | shuffle [<page ranges> | + | Also see the flatten, need_appearances, and replacement_font options. |
- | | + | === background < |
- | | + | |
- | time from each page range to assemble the output PDF. If one | + | |
- | range runs out of pages, it continues with the remaining | + | |
- | | + | |
- | for cat, like reverse page ranges, multiple ranges from a | + | |
- | | + | |
- | help collate | + | |
- | burst Splits | + | Applies |
- | Also creates a report named doc_data.txt which is the same as | + | Pass the background PDF's filename after background like so: |
- | the output from dump_data. | + | |
- | | + | |
- | ple, if you want pages named page_01.pdf, | + | |
- | pass output page_%02d.pdf to pdftk. If the pattern is omit- | + | |
- | ted, then a default pattern g_%04d.pdf is appended and pro- | + | |
- | duces pages named pg_0001.pdf, | + | |
- | can be applied to the output by appending output options such | + | |
- | as owner_pw, e.g.: | + | |
- | pdftk in.pdf | + | <cli bash> |
+ | frater@supremae: | ||
+ | </ | ||
- | rotate [<page ranges> | + | Pdftk uses only the first page from the background |
- | Takes a single input PDF and rotates just the specified | + | This page is scaled and rotated as needed to fit the input page. |
- | pages. All other pages remain unchanged. | + | |
- | remains unchanged. | + | |
- | same notation as you would with cat, except you omit the | + | |
- | pages that you aren't rotating: | + | |
- | | + | If the input PDF does not have a transparent background (such as a PDF created from page scans) then the resulting background won't be visible |
- | | + | === multibackground |
- | The qualifier can be even or odd, and the page rotation can | + | Same as the background operation, but applies each page of the background PDF to the corresponding |
- | be north, south, east, west, left, right, or down. | + | If the input PDF has more pages than the stamp PDF, then the final stamp page is repeated across these remaining pages in the input PDF. |
- | Each option sets the page rotation as follows (in degrees): | + | === stamp <stamp PDF filename | - | PROMPT> === |
- | | + | |
- | +90, down: +180. left, right, and down make relative adjust- | + | |
- | ments to a page's rotation. | + | |
- | The given order of the pages doesn' | + | This behaves just like the background operation except it overlays |
- | | + | This works best if the stamp PDF page has a transparent background. |
+ | === multistamp <stamp PDF filename | - | PROMPT> === | ||
- | generate_fdf | + | Same as the stamp operation, but applies each page of the background PDF to the corresponding page of the input PDF. |
- | Reads a single input PDF file and generates an FDF file suit- | + | If the input PDF has more pages than the stamp PDF, then the final stamp page is repeated across these remaining pages in the input PDF. |
- | able for fill_form out of it to the given output filename or | + | |
- | (if no output is given) | + | |
- | | + | |
- | fill_form <FDF data filename | XFDF data filename | - | PROMPT> | + | === dump_data === |
- | Fills the single input PDF's form fields with the data from | + | |
- | an FDF file, XFDF file or stdin. Enter the data filename | + | |
- | after fill_form, or use - to pass the data via stdin, like | + | |
- | so: | + | |
- | pdftk form.pdf fill_form | + | Reads a single input PDF file and reports its metadata, bookmarks (a/k/a outlines), page metrics (media, rotation and labels), |
- | If the input FDF file includes Rich Text formatted data in | + | === dump_data_utf8 === |
- | | + | |
- | into the form fields as well as the plain text. Pdftk also | + | |
- | sets a flag that cues Reader/ | + | |
- | | + | |
- | opens the PDF, the viewer will create the Rich Text appear- | + | |
- | ance on the spot. If the user's PDF viewer does not support | + | |
- | Rich Text, then the user will see the plain text data | + | |
- | | + | |
- | | + | |
- | plain text field data is what you'll see. | + | |
- | Also see the flatten, need_appearances, | + | Same as dump_data except that the output is encoded as UTF-8. |
- | | + | |
- | background < | + | === dump_data_fields === |
- | | + | |
- | | + | |
- | like so: | + | |
- | pdftk in.pdf background back.pdf output out.pdf | + | Reads a single input PDF file and reports form field statistics to the given output filename or (if no output is given) to stdout. Non-ASCII characters are encoded as XML numerical entities. Does not create a new PDF. |
- | Pdftk uses only the first page from the background PDF and | + | === dump_data_fields_utf8 === |
- | | + | |
- | | + | |
- | use - to pass a background PDF into pdftk via stdin. | + | |
- | | + | Same as dump_data_fields except that the output is encoded |
- | as a PDF created from page scans) then the resulting back- | + | |
- | | + | |
- | multibackground < | + | === dump_data_annots === |
- | Same as the background operation, but applies each page of | + | |
- | the background PDF to the corresponding page of the input | + | |
- | | + | |
- | then the final stamp page is repeated across these remaining | + | |
- | pages in the input PDF. | + | |
- | stamp <stamp PDF filename | - | PROMPT> | + | This operation |
- | This behaves just like the background | + | |
- | | + | |
- | | + | |
- | | + | |
- | multistamp | + | === update_info |
- | Same as the stamp operation, but applies each page of the | + | |
- | | + | |
- | If the input PDF has more pages than the stamp PDF, then the | + | |
- | final stamp page is repeated across these remaining pages in | + | |
- | the input PDF. | + | |
- | dump_data | + | Changes the bookmarks, page labels, page sizes, page rotations, and metadata in a single PDF' |
- | Reads a single input PDF file and reports its metadata, book- | + | |
- | marks (a/k/a outlines), page metrics (media, rotation | + | |
- | | + | |
- | | + | |
- | | + | |
- | as XML numerical entities. Does not create a new PDF. | + | |
- | dump_data_utf8 | + | This operation does not change |
- | Same as dump_data except that the output is encoded as UTF-8. | + | |
- | dump_data_fields | + | For example: |
- | Reads a single input PDF file and reports form field statis- | + | |
- | tics to the given output filename or (if no output is given) | + | |
- | to stdout. Non-ASCII characters are encoded as XML numerical | + | |
- | | + | |
- | dump_data_fields_utf8 | + | <cli bash> |
- | Same as dump_data_fields except that the output | + | frater@supremae: |
- | UTF-8. | + | </ |
- | dump_data_annots | + | === update_info_utf8 <info data filename |
- | This operation currently reports only link annotations. | + | |
- | Reads a single input PDF file and reports annotation informa- | + | |
- | tion to the given output | + | |
- | to stdout. Non-ASCII characters are encoded as XML numerical | + | |
- | | + | |
- | | + | Same as update_info |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | This operation does not change the metadata stored in the | + | === attach_files < |
- | | + | |
- | | + | |
- | | + | |
- | - omitted data after YYYY revert to default values.) | + | |
- | For example: | + | Packs arbitrary files into a PDF using PDF's file attachment features. More than one attachment may be listed after attach_files. Attachments are added at the document level unless the optional to_page option is given, in which case the files are attached to the given page number (the first page is 1, the final page is end). Attachments at the document level may be tagged with a relationship among Source, Data, Alternative, |
- | pdftk in.pdf update_info in.info output out.pdf | + | For example: |
- | update_info_utf8 | + | <cli bash> |
- | Same as update_info except that the input is encoded as | + | frater@supremae: |
- | UTF-8. | + | </ |
- | attach_files | + | <cli bash> |
- | | + | frater@supremae: |
- | Packs arbitrary files into a PDF using PDF's file attachment | + | </ |
- | | + | === unpack_files === |
- | attach_files. Attachments are added at the document level | + | |
- | | + | |
- | the files are attached to the given page number (the first | + | |
- | page is 1, the final page is end). Attachments at the docu- | + | |
- | ment level may be tagged with a relationship among Source, | + | |
- | Data, Alternative, | + | |
- | For example: | + | Copies all of the attachments from the input PDF into the current folder or to an output directory given after output. |
- | pdftk in.pdf attach_files table1.html table2.html to_page 6 | + | For example: |
- | | + | |
- | pdftk in.pdf attach_files in.tex relation Source | + | <cli bash> |
- | out.pdf | + | frater@supremae: |
+ | </ | ||
- | unpack_files | + | or, interactively: |
- | | + | |
- | | + | |
- | For example: | + | |
- | pdftk report.pdf unpack_files output | + | <cli bash> |
+ | frater@supremae: | ||
+ | </cli> | ||
+ | === [output <output filename | - | PROMPT>] === | ||
- | or, interactively: | + | The output PDF filename may not be set to the name of an input filename. Use - to output to stdout. |
+ | When using the dump_data operation, use output to set the name of the output data file. When using the unpack_files operation, use output to set the name of an output directory. | ||
- | pdftk report.pdf unpack_files | + | === [encrypt_40bit | encrypt_128bit | encrypt_aes128] === |
+ | |||
+ | If an output | ||
- | [output | + | === [allow <permissions>] === |
- | The output PDF filename may not be set to the name of an input | + | |
- | filename. Use - to output to stdout. | + | |
- | operation, use output to set the name of the output data file. | + | |
- | When using the unpack_files operation, use output to set the | + | |
- | name of an output directory. | + | |
- | you can use output to control the resulting PDF page filenames | + | |
- | (described above). | + | |
- | | + | Permissions are applied to the output PDF only if an encryption strength is specified |
- | If an output PDF user or owner password is given, the output PDF | + | If permissions are not specified, they default to ' |
- | encryption algorithm defaults to AES-128. The weaker RC4 40-bit | + | |
- | and RC4 128-bit algorithms can be chosen by specifying | + | |
- | encrypt_40bit or encrypt_128bit (discouraged). | + | |
- | | + | The permissions |
- | Permissions are applied to the output PDF only if an encryption | + | {{tablelayout? |
- | | + | ^ Printing |
- | | + | ^ DegradedPrinting |
- | | + | ^ ModifyContents |
+ | ^ Assembly | ||
+ | ^ CopyContents | ||
+ | ^ ScreenReaders | ||
+ | ^ ModifyAnnotations | ||
+ | ^ FillIn | ||
+ | ^ AllFeatures | ||
- | The permissions section may include one or more of the following | + | === [owner_pw <owner password | PROMPT>] === |
- | features: | + | |
- | Printing | + | === [user_pw <user password | PROMPT>] === |
- | Top Quality Printing | + | |
- | DegradedPrinting | + | If an encryption strength is given but no passwords are supplied, then the owner and user passwords remain empty, which means that the resulting PDF may be opened and its security parameters altered by anybody. |
- | Lower Quality Printing | + | |
- | ModifyContents | + | === [compress | uncompress] === |
- | Also allows Assembly | + | |
- | Assembly | + | These are only useful when you want to edit PDF code in a text editor like vim or emacs. |
+ | Remove PDF page stream compression by applying the uncompress filter. Use the compress filter to restore compression. | ||
- | CopyContents | + | === [flatten] === |
- | Also allows ScreenReaders | + | |
- | ScreenReaders | + | Use this option to merge an input PDF's interactive form fields (and their data) with the PDF's pages. Only one input PDF may be given. Sometimes used with the fill_form operation. |
- | ModifyAnnotations | + | === [need_appearances] === |
- | Also allows FillIn | + | |
- | FillIn | + | Sets a flag that cues Reader/ |
- | AllFeatures | + | === [replacement_font <font name>] === |
- | | + | |
- | | + | |
- | | + | Use the specified font to display text in form fields. This option is useful when filling a form with non-ASCII text that is not supported by the fonts included in the input PDF. font name may be either the file name or the family name of a font, but using a file name is more reliable. Currently only TrueType fonts with Unicode text are supported. |
- | [user_pw <user password | + | === [keep_first_id |
- | If an encryption strength is given but no passwords are sup- | + | |
- | plied, then the owner and user passwords remain empty, which | + | |
- | means that the resulting PDF may be opened and its security | + | |
- | parameters altered by anybody. | + | |
- | | + | When combining pages from multiple PDFs, use one of these options |
- | These are only useful when you want to edit PDF code in a text | + | |
- | editor like vim or emacs. | + | |
- | applying | + | |
- | restore compression. | + | |
- | [flatten] | + | === [drop_xfa] === |
- | Use this option to merge an input PDF's interactive form fields | + | |
- | (and their data) with the PDF's pages. Only one input PDF may be | + | |
- | given. Sometimes used with the fill_form operation. | + | |
- | | + | If your input PDF is a form created using Acrobat 7 or Adobe Designer, then it probably has XFA data. |
- | Sets a flag that cues Reader/ | + | Filling such a form using pdftk yields a PDF with data that fails to display |
- | appearances based on the form field values. Use this when fill- | + | The workaround solution is to remove |
- | | + | |
- | | + | |
- | the flatten | + | |
- | | + | This option is only useful when running pdftk on a single |
- | Use the specified font to display text in form fields. | + | When assembling |
- | | + | |
- | not supported by the fonts included in the input PDF. font name | + | |
- | may be either the file name or the family name of a font, but | + | |
- | using a file name is more reliable. Currently only TrueType | + | |
- | fonts with Unicode text are supported. | + | |
- | [keep_first_id | keep_final_id] | + | === [drop_xmp] === |
- | When combining pages from multiple PDFs, use one of these | + | |
- | options to copy the document ID from either the first or final | + | |
- | input document into the new output PDF. Otherwise pdftk creates | + | |
- | a new document ID for the output PDF. When no operation is | + | |
- | given, pdftk always uses the ID from the (single) input PDF. | + | |
- | | + | Many PDFs store document metadata |
- | If your input PDF is a form created | + | Pdftk' |
- | Designer, then it probably has XFA data. Filling such a form | + | The proper remedy for this is to include a ModDate entry in your updated info with a current date/ |
- | using pdftk yields a PDF with data that fails to display in | + | The date/ |
- | Acrobat 7 (and 6?). The workaround solution is to remove the | + | |
- | form' | + | |
- | at the time you fill the form. Using this option causes pdftk to | + | |
- | | + | |
- | This option | + | Alternatively, |
- | PDF. | + | Note that objects inside the PDF might have their own, separate XMP metadata streams, and that drop_xmp does not remove those. |
- | any XFA data in the input is automatically omitted. | + | |
- | [drop_xmp] | + | === [verbose] === |
- | Many PDFs store document metadata using both an Info dictionary | + | |
- | (old school) and an XMP stream (new school). | + | |
- | update_info operation can update the Info dictionary, but not | + | |
- | the XMP stream. | + | |
- | ModDate entry in your updated info with a current date/ | + | |
- | stamp. The date/ | + | |
- | D: | + | |
- | ues. This newer ModDate should cue PDF viewers that the Info | + | |
- | metadata is more current than the XMP data. | + | |
- | Alternatively, you might prefer | + | By default, pdftk runs quietly. Append verbose |
- | the PDF altogether - that's what this option does. Note that | + | |
- | objects inside the PDF might have their own, separate XMP meta- | + | |
- | data streams, | + | |
- | removes the PDF's document-level XMP stream. | + | |
- | [verbose] | + | === [dont_ask | do_ask] === |
- | By default, pdftk runs quietly. Append verbose to the end and it | + | |
- | will speak up. | + | |
- | | + | Depending on the compile-time settings (see ASK_ABOUT_WARNINGS), |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | When running in dont_ask mode, pdftk will over-write files with its output without notice. |
- | | + | |
==== EXAMPLES ==== | ==== EXAMPLES ==== |