Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédente | |||
pdftk_usage_et_exemple [2025/01/29 12:03] – [shuffle [<page ranges>]] 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> |
| | ||
< | < | ||
Ligne 221: | Ligne 221: | ||
For example, if you want pages named page_01.pdf, | 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.: | 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: | ||
+ | |||
< | < | ||
- | pdftk in.pdf burst owner_pw foopass | + | [<begin page number> |
</ | </ | ||
- | === rotate [<page ranges>] === | ||
- | Takes a single input PDF and rotates just the specified | ||
- | | ||
- | | ||
- | same notation as you would with cat, except you omit the | ||
- | pages that you aren't rotating: | ||
- | | + | The qualifier |
- | rotation>] | + | |
- | The qualifier can be even or odd, and the page rotation | + | Each option sets the page rotation |
- | be north, south, east, west, left, right, or down. | + | |
- | Each option sets the page rotation as follows (in degrees): | + | * north: 0, |
- | north: 0, east: 90, south: 180, west: 270, left: -90, right: | + | * east: 90, |
- | +90, down: +180. left, right, and down make relative adjust- | + | * south: 180, |
- | ments to a page's rotation. | + | * west: 270, |
+ | * left: -90, | ||
+ | * right: +90, | ||
+ | * down: +180. | ||
- | The given order of the pages doesn' | + | //left//, //right//, and //down// make relative adjustments to a page's rotation. |
- | the output. | + | |
+ | The given order of the pages doesn' | ||
=== generate_fdf === | === generate_fdf === | ||
- | Reads a single input PDF file and generates an FDF file suit- | + | |
- | | + | Reads a single input PDF file and generates an FDF file suitable |
- | (if no output is given) to stdout. | + | |
- | PDF. | + | |
=== fill_form <FDF data filename | XFDF data filename | - | PROMPT> === | === fill_form <FDF data filename | XFDF data filename | - | PROMPT> === | ||
- | Fills the single input PDF's form fields with the data from | + | |
- | an FDF file, XFDF file or stdin. Enter the data filename | + | 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: |
- | after fill_form, or use - to pass the data via stdin, like | + | |
- | so: | + | |
- | pdftk form.pdf fill_form data.fdf output form.filled.pdf | + | < |
+ | frater@host: | ||
+ | </ | ||
- | If the input FDF file includes Rich Text formatted data in | ||
- | | ||
- | 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, and replacement_font | + | 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. |
- | options. | + | Pdftk also sets a flag that cues Reader/ |
+ | So when the user opens the PDF, the viewer will create the Rich Text appearance on the spot. | ||
+ | If the user's PDF viewer does not support Rich Text, then the user will see the plain text data instead. | ||
+ | If you flatten this form before Acrobat has a chance to create (and save) new field appearances, | ||
+ | Also see the flatten, need_appearances, | ||
=== background < | === background < | ||
- | | ||
- | | ||
- | like so: | ||
- | pdftk in.pdf | + | Applies a PDF watermark to the background |
+ | Pass the background PDF's filename after background like so: | ||
- | Pdftk uses only the first page from the background PDF and | + | <cli bash> |
- | applies it to every page of the input PDF. This page is | + | frater@supremae: |
- | | + | </ |
- | use - to pass a background PDF into pdftk via stdin. | + | |
- | | + | Pdftk uses only the first page from the background PDF and applies it to every page of the input PDF. |
- | as a PDF created from page scans) then the resulting back- | + | This page is scaled and rotated as needed to fit the input page. You can use - to pass a background PDF into pdftk via stdin. |
- | ground won't be visible - use the stamp operation instead. | + | |
+ | 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 - use the stamp operation instead. | ||
=== multibackground < | === multibackground < | ||
- | Same as the background operation, but applies each page of | + | |
- | the background PDF to the corresponding page of the input | + | Same as the background operation, but applies each page of the background PDF to the corresponding page of the input PDF. |
- | PDF. If the input PDF has more pages than the stamp PDF, | + | 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. |
- | then the final stamp page is repeated across these remaining | + | |
- | pages in the input PDF. | + | |
=== stamp <stamp PDF filename | - | PROMPT> === | === stamp <stamp PDF filename | - | PROMPT> === | ||
- | This behaves just like the background operation except it | ||
- | | ||
- | | ||
- | | ||
+ | This behaves just like the background operation except it overlays the stamp PDF page on top of the input PDF document' | ||
+ | This works best if the stamp PDF page has a transparent background. | ||
=== multistamp <stamp PDF filename | - | PROMPT> === | === multistamp <stamp PDF filename | - | PROMPT> === | ||
- | Same as the stamp operation, but applies each page of the | + | |
- | background PDF to the corresponding page of the input PDF. | + | Same as the stamp operation, but applies each page of the background PDF to the corresponding page of the input PDF. |
- | | + | 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. |
- | final stamp page is repeated across these remaining pages in | + | |
- | the input PDF. | + | |
=== dump_data === | === dump_data === | ||
- | Reads a single input PDF file and reports its metadata, | + | |
- | | + | Reads a single input PDF file and reports its metadata, |
- | labels), data embedded by STAMPtk (see STAMPtk' | + | |
- | option) and other data to the given output filename or (if no | + | |
- | output is given) to stdout. | + | |
- | as XML numerical entities. | + | |
=== dump_data_utf8 === | === dump_data_utf8 === | ||
- | Same as dump_data except that the output is encoded as UTF-8. | + | |
+ | Same as dump_data except that the output is encoded as UTF-8. | ||
=== dump_data_fields === | === dump_data_fields === | ||
- | Reads a single input PDF file and reports form field statis- | + | |
- | | + | Reads a single input PDF file and reports form field statistics |
- | to stdout. Non-ASCII characters are encoded as XML numerical | + | |
- | entities. Does not create a new PDF. | + | |
=== dump_data_fields_utf8 === | === dump_data_fields_utf8 === | ||
- | Same as dump_data_fields except that the output is encoded as | + | |
- | UTF-8. | + | Same as dump_data_fields except that the output is encoded as UTF-8. |
=== dump_data_annots === | === dump_data_annots === | ||
- | This operation currently reports only link annotations. | + | |
- | Reads a single input PDF file and reports annotation | + | This operation currently reports only link annotations. Reads a single input PDF file and reports annotation |
- | | + | |
- | to stdout. Non-ASCII characters are encoded as XML numerical | + | |
- | entities. Does not create a new PDF. | + | |
=== update_info <info data filename | - | PROMPT> === | === update_info <info data filename | - | PROMPT> === | ||
- | | ||
- | | ||
- | match the input data file. The input data file uses the same | ||
- | | ||
- | | ||
- | This operation does not change | + | Changes |
- | PDF' | + | |
- | | + | |
- | | + | |
- | - omitted data after YYYY revert to default values.) | + | |
- | For example: | + | This operation does not change the metadata stored in the PDF's XMP stream, if it has one. (For this reason you should include a ModDate entry in your updated info with a current date/ |
- | pdftk in.pdf update_info in.info output out.pdf | + | For example: |
+ | |||
+ | <cli bash> | ||
+ | frater@supremae: | ||
+ | </ | ||
=== update_info_utf8 <info data filename | - | PROMPT> === | === update_info_utf8 <info data filename | - | PROMPT> === | ||
- | Same as update_info except that the input is encoded as | + | |
- | UTF-8. | + | Same as update_info except that the input is encoded as UTF-8. |
=== attach_files < | === attach_files < | ||
- | Packs arbitrary files into a PDF using PDF's file attachment | ||
- | | ||
- | | ||
- | | ||
- | 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: | + | 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 attach_files table1.html table2.html to_page 6 | + | For example: |
- | | + | |
- | pdftk in.pdf attach_files | + | <cli bash> |
- | out.pdf | + | frater@supremae: |
+ | </ | ||
+ | <cli bash> | ||
+ | frater@supremae: | ||
+ | </ | ||
=== unpack_files === | === unpack_files === | ||
- | Copies all of the attachments from the input PDF into the | + | Copies all of the attachments from the input PDF into the current folder or to an output directory given after output. |
- | current folder or to an output directory given after output. | + | |
- | For example: | + | |
- | pdftk report.pdf unpack_files output ~/atts/ | + | For example: |
- | or, interactively: | + | <cli bash> |
+ | frater@supremae:$ pdftk report.pdf unpack_files output ~/atts/ | ||
+ | </ | ||
- | pdftk report.pdf unpack_files output PROMPT | + | or, interactively: |
+ | <cli bash> | ||
+ | frater@supremae: | ||
+ | </ | ||
=== [output <output filename | - | PROMPT>] === | === [output <output filename | - | PROMPT>] === | ||
- | | + | |
- | | + | 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. |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
=== [encrypt_40bit | encrypt_128bit | encrypt_aes128] === | === [encrypt_40bit | encrypt_128bit | encrypt_aes128] === | ||
- | If an output PDF user or owner password is given, the output PDF | + | |
- | | + | If an output PDF user or owner password is given, the output PDF 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). |
- | | + | |
- | | + | |
=== [allow < | === [allow < | ||
- | Permissions are applied to the output PDF only if an encryption | ||
- | strength is specified or an owner or user password is given. | ||
- | permissions are not specified, they default to ' | ||
- | means all of the following features are disabled. | ||
- | The permissions section may include one or more of the following | + | Permissions are applied to the output PDF only if an encryption strength is specified |
- | | + | If permissions are not specified, they default to ' |
- | Printing | + | The permissions section may include one or more of the following features: |
- | | + | {{tablelayout? |
- | + | ^ Printing | |
- | | + | ^ DegradedPrinting |
- | Lower Quality Printing | + | ^ ModifyContents |
- | + | ^ Assembly | |
- | | + | ^ CopyContents |
- | Also allows Assembly | + | ^ ScreenReaders |
- | + | ^ ModifyAnnotations | |
- | | + | ^ FillIn |
- | + | ^ AllFeatures | |
- | | + | |
- | Also allows ScreenReaders | + | |
- | + | ||
- | | + | |
- | + | ||
- | | + | |
- | Also allows FillIn | + | |
- | + | ||
- | | + | |
- | + | ||
- | | + | |
- | Allows the user to perform all of the above, and top | + | |
- | quality printing. | + | |
=== [owner_pw <owner password | PROMPT>] === | === [owner_pw <owner password | PROMPT>] === | ||
=== [user_pw <user password | PROMPT>] === | === [user_pw <user password | PROMPT>] === | ||
- | | + | |
- | plied, then the owner and user passwords remain empty, which | + | 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. |
- | | + | |
- | | + | |
=== [compress | uncompress] === | === [compress | uncompress] === | ||
- | | + | |
- | | + | 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. |
- | | + | |
=== [flatten] === | === [flatten] === | ||
- | | + | |
- | | + | 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. |
- | | + | |
=== [need_appearances] === | === [need_appearances] === | ||
- | | + | |
- | | + | Sets a flag that cues Reader/ |
- | ing a form with non-ASCII text to ensure the best presentation | + | |
- | | + | |
- | | + | |
=== [replacement_font <font name>] === | === [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. |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
=== [keep_first_id | keep_final_id] === | === [keep_first_id | keep_final_id] === | ||
- | | + | |
- | | + | 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. |
- | | + | |
- | | + | |
- | | + | |
=== [drop_xfa] === | === [drop_xfa] === | ||
- | If your input PDF is a form created using Acrobat 7 or Adobe | ||
- | Designer, then it probably has XFA data. Filling such a form | ||
- | using pdftk yields a PDF with data that fails to display in | ||
- | Acrobat 7 (and 6?). The workaround solution is to remove the | ||
- | form's XFA data, either before you fill the form using pdftk or | ||
- | at the time you fill the form. Using this option causes pdftk to | ||
- | omit the XFA data from the output PDF form. | ||
- | | + | If your input PDF is a form created using Acrobat 7 or Adobe Designer, then it probably has XFA data. |
- | | + | Filling such a form using pdftk yields a PDF with data that fails to display in Acrobat 7 (and 6?). |
- | | + | The workaround solution is to remove the form's XFA data, either before you fill the form using pdftk or at the time you fill the form. Using this option causes pdftk to omit the XFA data from the output PDF form. |
+ | |||
+ | This option is only useful when running pdftk on a single input PDF. | ||
+ | When assembling a PDF from multiple inputs using pdftk, any XFA data in the input is automatically omitted. | ||
=== [drop_xmp] === | === [drop_xmp] === | ||
- | 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/time- | ||
- | stamp. The date/ | ||
- | D: | ||
- | ues. This newer ModDate should cue PDF viewers that the Info | ||
- | metadata is more current than the XMP data. | ||
- | | + | Many PDFs store document metadata using both an Info dictionary (old school) and an XMP stream (new school). |
- | | + | Pdftk' |
- | | + | The proper remedy for this is to include a ModDate entry in your updated info with a current date/ |
- | data streams, and that drop_xmp does not remove those. | + | The date/ |
- | | + | |
+ | Alternatively, | ||
+ | Note that objects inside the PDF might have their own, separate XMP metadata | ||
=== [verbose] === | === [verbose] === | ||
- | | + | |
- | | + | By default, pdftk runs quietly. Append verbose to the end and it will speak up. |
=== [dont_ask | do_ask] === | === [dont_ask | do_ask] === | ||
- | Depending on the compile-time settings (see ASK_ABOUT_WARNINGS), | ||
- | pdftk might prompt you for further input when it encounters a | ||
- | problem, such as a bad password. Override this default behavior | ||
- | by adding dont_ask (so pdftk won't ask you what to do) or do_ask | ||
- | (so pdftk will ask you what to do). | ||
- | | + | 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 ==== |