While a handle of a Fill & Sign line, check, cross, dot, typed signature
or comment stamp was dragged, only the selection frame followed the
pointer; the stamp kept its old size (or place) until release. Image
signatures already had a live layer. Every stamp now gets one: the page
without the stamp, and the stamp drawn alone on a transparent page,
whose pixels are stretched with the frame. Resizing a stamp only changes
its /Rect, which its appearance is stretched to fit, so the preview is
what the release produces.
- render: RenderConfig.transparent clears the page to transparent.
- annot: isolate_annotation leaves a page showing one annotation alone.
- engine: Document::stamp_preview builds the two read-only layers; the
page beneath gets the appearances drawn for comments without one.
- ui-egui: the signature drag layer covers every stamp, rendering the
stamp's own tile sharp at the current zoom.
Revisions 5-6 of the standard security handler key the file on the
password processed with SASLprep (ISO 32000-2 7.6.4.3.3, Algorithm 2.A
step a). pdfcraft-crypt writes and reads it so, but the vendored
hayro-syntax skipped the step ("TODO: Do the above.") and used the UTF-8
bytes as typed. A password that SASLprep changes (a decomposed "cafe" +
U+0301, a no-break space, fullwidth letters typed by an IME in full-width
mode) was wrong for the renderer: Protect with such an open password was
rolled back ("the password is incorrect"), and an AES-256 file with such a
password did not open in a session with it, although pdfcraft-cos
accepted it.
- hayro-syntax (vendored patch 16) tries an R5/R6 password in its SASLprep
form (as pdfcraft-crypt computes it: as given if SASLprep refuses it,
UTF-8, at most 127 bytes), then, when that differs, as given.
stringprep, already in the tree through pdfcraft-crypt, is an optional
dependency enabled by the std feature; without std nothing changes.
- Tests: hayro-syntax crypto::pdfcraft_password_tests (candidate list and
R5/R6 dictionaries built from prepared passwords) and two engine tests
(Protect and reopen, and pdfcraft-cos-encrypted files) for the three
cases, with precomposed "caf\u{E9}" as the control. The dictionary test
and both engine tests fail without the fix.
Fixes#1296.
Encryption derives its keys from a prepared password, not the typed one:
AES-256 (R6) applies SASLprep, falls back to the password as given if
SASLprep refuses it, and truncates the UTF-8 to 127 bytes; RC4/AES-128
(R2-R4) use PDFDocEncoding cut or padded to exactly 32 bytes, and the
padding starts with "(". Protection::validate checked only the typed
strings, so a permissions password of U+00AD wrote a file that opens with
owner rights and no password, and an open password "A" with a permissions
password U+FF21 (or RC4/AES-128 passwords "a"x31 and "a"x31 + "(") wrote a
file whose open password lifts the restrictions.
pdfcraft-crypt gains effective_password(algorithm, password), the bytes the
keys are derived from (it and create share the private prepared_password
helper), re-exported from pdfcraft-cos. validate refuses a password whose
effective bytes are those of "", and an open and a permissions password
whose effective bytes are equal. Opening files is unchanged.
Fixes#1185.
* Issue #568: honour the document's copy permission
ISO 32000-2 §7.6.4.1 has readers restrict access to an encrypted file
according to its permissions, and Table 22 bit 5 covers "Copy or otherwise
extract text and graphics". PdfCraft reported the bit (Document Properties
shows "Content copying: Not allowed") but ⌘C copied selected text anyway.
- Engine: Document::allows_copying / check_copying, and Needs::Copying for
Take a snapshot, Export to image/text/Word/HTML/RTF and Export all images.
Save Image As refuses too.
- UI: ⌘C moves from canvas::shortcuts to the app, which knows the document.
Refused copies, snapshots and exports say why. The snapshot tool and the
exports check again when they act, since the tool stays selected across tabs.
- Automation: text_extract (and the MCP text resources), text_paragraphs,
doc_export_text/images/all_images, doc_export_office and image_save refuse.
Find, read aloud and the accessibility tools keep working: the spec exempts
assistive technology, and searching isn't copying. Page extraction stays with
the assemble bit, as before. Owners and unencrypted files are unaffected.
* Refresh catalog hashes
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Issue #870: keys leave the document under a dialog alone
With Preferences (or any other dialog) open, the registered shortcuts still
ran on the document underneath it: ⌘W / Ctrl+W closed the file, ⌘Z undid an
edit, ⌘F opened Find. In Organize Pages the grid's own keys did too, so Delete
or Backspace deleted the selected pages behind the dialog, and the grid took
the Escape meant to close it.
Every modal now owns the keyboard, as "Save changes?" already did:
PdfCraftApp::modal_open covers the dialog, the save, password and link
prompts and the update check. Shortcuts stop there, and the organize grid's
keys and autoscroll wait until the page is unobstructed.
* Contributors: credit jay-tau by their GitHub profile name
Joel Tony