# Compatibililty notes for pdftl

pdftl aspires to be CLI compatible with pdftk and this is an attempt to explain what this might mean, and to note any caveats.

## What is CLI compatibility?

The vague idea is clear: `s/pdftk/pdftl/g` should Just Work.

So the questions are:

1. Which pdftk implementation are we targeting?

2. What is Just Working?

We don't really know the answers. Our approach is to take existing integration tests for various pdftk implementations and to check whether or not pdftl passes them.

Getting pdftl to pass them all is the goal.

## Known compatibility bugs

None right now. [Please report if you find any][1].

[1]: https://github.com/pdftl/pdftl/issues

## Compatibility caveats and issues

- Order of lines in `dump_data` etc may differ from pdftk, where not semantically important.

- FDF files generated by `generate_fdf` are formatted differently than pdftk's, to be more human-readable.

- `update_info` cannot reset the PdfID1 field in pdftl, but it can in pdftk. In pdftl, the PdfID1 field is generated automatically by the underlying qpdf library on save. pdftl *can* reset both fields to be new, equal IDs, mimicking a "freshly baked" PDF file. For more, read `pdftl help update_info`.

- It is not possible to deny the "screenreader" (a.k.a. "accessibility") permission in files saved with pdftl. This is a limitation of the underlying qpdf library, to align with the modern PDF specification.
