M4: custom document properties through the engine and the tools

[mtlcl410]

What this changes

Custom document properties (Acrobat's Document Properties ▸ Custom: name/value pairs kept in /Info beside the standard entries), through the engine and the tools. The dialog's Custom tab is a follow-up, after #2012 lands on dialogs.rs.

• pdfcraft-organize: custom_info lists every /Info entry whose key the spec does not name (STANDARD_INFO_KEYS, table 349) and whose value is text, at most 256. check_custom_key applies the rules Acrobat applies to a custom name: not a standard name, not empty, at most 127 bytes (the name length every reader must accept, Annex C), and none of whitespace, the delimiters ()<>[]{}/% or #, so the name reads the same everywhere. set_info runs that check for any non-standard key, so a custom entry is set and cleared exactly as Title and Author are (and undone as one step, labelled "Change {key}" as before).
• pdfcraft-render: DocInfo::custom, the same list from inspection, so an opened file shows its custom entries at once.
• pdfcraft-engine: Document::custom_info, and the metadata refresh after an edit keeps info.custom current.
• pdfcraft-automation: doc_info lists them under custom (name, value), and doc_set_info's description says custom names are accepted and how they are checked. pdfcraft-cli info adds a custom_properties count.
• parity/: organize.custom-properties becomes partial with what is still missing (the Custom tab; mirroring into XMP pdfx: as Acrobat does).

How you verified it

• cargo fmt --check
• cargo clippy -p pdfcraft-organize -p pdfcraft-render -p pdfcraft-engine -p pdfcraft-automation -p pdfcraft-cli -j 2 --all-targets -- -D warnings
• cargo test -p pdfcraft-organize -j 2 (120 passed), cargo test -p pdfcraft-render -j 2 --lib (272), cargo test -p pdfcraft-automation -j 2 --test automation (155)
• cargo xtask parity, cargo xtask layers

Tests, each shown failing with the listing disabled (custom_info returning nothing; inspection taking no custom entry) and passing with it:

• organize::tests::custom_document_properties_are_listed_set_removed_and_their_names_checked: Title plus Project and Revision set; only the two custom ones are listed; clearing one and saving keeps the other; the refused names (empty, Title, ModDate, a space, /, a tab, #, parentheses, 128 bytes) and the accepted ones (Project, Révision, 部門, key-2.0, 127 bytes); set_info with a bad name changes nothing.
• inspect::tests::custom_document_properties_are_listed_apart_from_the_standard_ones: an /Info with Title, Producer, Project, a numeric Revision, Dept (R&D), Trapped and a UTF-16 Note: the three text custom entries are listed, the number and the standard entries are not.
• custom_document_properties_are_set_listed_and_cleared_through_the_tools: doc_set_info sets two custom entries and doc_info lists them apart from Title; a name with a space and an empty name are refused; clearing one, saving and reopening lists the one left with its value.

Never-crash

• No new unwrap/expect/indexing outside tests; the custom list is capped at 256 entries; a name over 127 bytes is refused before it reaches the writer
• No unsafe

Provenance

• Behaviour from ISO 32000-2 §7.3.5, Annex C and table 349, and Acrobat's documented Custom tab rules; no assets, no external code

Security

• No paths, MCP, control channel or network involved

Parity and reach

• organize.custom-properties updated with evidence and what is still missing; tools doc_info and doc_set_info cover it headlessly

🤖 Generated with Claude Code