Set an entry in an attachment's /Params dictionary
Source: R/attachment_authoring.R
pdf_attachment_set_dict_value.RdWrites a string-valued entry in the attachment's parameter dictionary. Common keys:
Arguments
- att
A
pdfium_attachmentfrompdf_attachments()orpdf_attachment_new(). Parent doc must be readwrite.- key
The dictionary key as a non-empty character scalar.
- value
The string value as a character scalar; UTF-8 accepted.
Details
"Desc"— a human-readable description."AFRelationship"— the AF/EF relationship type ("Source","Data","Alternative", etc.)."ModDate"— modification date as a PDF date string (seepdf_parse_date()for the format).
Wraps FPDFAttachment_SetStringValue, which writes into the
attachment's /Params subdictionary. Mirrors
pdf_attachment_dict_value() on the read side.
Ordering: PDFium's FPDFAttachment_SetStringValue requires the
attachment's /Params dictionary to already exist. Call
pdf_attachment_set_data() first on any attachment that doesn't
have one yet (the file data write auto-creates /Params,
populating Size, CreationDate, and CheckSum); only then can
you append further keys with this function. On a fresh attachment
from pdf_attachment_new() this means the natural sequence is
pdf_attachment_new() → pdf_attachment_set_data() →
pdf_attachment_set_dict_value().
Not exposed: the file stream's own /Subtype entry (the MIME
type returned by pdf_attachment_mime_type()) lives on the
attachment's embedded file stream, not on /Params, and PDFium
has no public setter for it. Passing key = "Subtype" here writes
/Params/Subtype, which won't be picked up by
pdf_attachment_mime_type(). See dev/upstream-patches/ for the
upstream gap.
Encoding: PDFium's FPDFAttachment_SetStringValue stores the
value as a PDF byte-string interpreted in PDFDocEncoding on read.
ASCII round-trips cleanly; non-ASCII Unicode characters are
lossy through the read path (the bytes are written but
FPDFAttachment_GetStringValue's GetUnicodeText step
misinterprets multi-byte UTF-8 sequences as PDFDocEncoding bytes).
This is a PDFium-side inconsistency — FPDFAnnot_SetStringValue
uses the wide-string-aware CPDF_String path and round-trips
Unicode correctly. Until upstream is fixed, restrict
attachment-dict values to ASCII when round-trip fidelity matters.