Windows Signature Appearance Profiles
The Windows sign operation can generate a visible Unicode signature appearance from a named built-in preset and an explicitly supplied embeddable TrueType font
{"schemaVersion":1,"type":"sign","incremental":true,
"existingField":true,"fieldName":"ApprovalOne",
"pfxFile":"C:/keys/signer.pfx","pfxPassword":"password",
"appearance":{"profileName":"HotPDF.StandardApproval",
"text":"Signed by Alice","fontFile":"C:/fonts/DejaVuSans.ttf"}}Actual preset selection
| profileName | Generated configuration |
|---|---|
| HotPDF.StandardApproval | 11 pt centred blue text, 4 pt padding, a rectangle border, a white background, and a single text line |
| HotPDF.StandardCertification | 10 pt left-aligned black text, 5 pt padding, a rectangle border, a white background, multiline wrapping, and 1.35 line spacing |
| HotPDF.Compact | 8 pt right-aligned black text, 1 pt padding, no painted background or border, and a single text line |
The selected preset configures the actual producer rather than labelling caller-defined visual options; these are the same configurations returned by HPDFSelectHeadlessSignatureAppearanceProfile
text supplies the actual caption and fontFile supplies its TrueType program; both are required, nonempty Unicode strings, and all three appearance strings are limited to 16,384 UTF-8 bytes with no NUL
Font embedding permissions, Unicode validity, available glyphs, complex shaping requirements, caption fit, and configured limits are enforced during generation
Widgets and signed documents
Generation updates the normal AP/N Form XObject for every Widget belonging to the selected signature field, including merged fields and fields with separate Widget children
Each Widget supplies its own positive rectangle dimensions and optional MK/R rotation of 0, 90, 180, or 270 degrees; preset alignment takes precedence over inherited alignment hints
Rollover and down appearances are preserved when an existing AP dictionary is present; malformed geometry, appearance dictionaries, rotations, or cyclic Widget hierarchies reject generation
The signing operation supports existing fields, new fields, incremental encrypted updates, unsigned-document signing, first certification signatures, and subsequent approval signatures permitted by P2 or P3 and field-lock policies
Use certificationPermission to select actual certification behaviour; choosing the StandardCertification appearance alone does not certify the document
Generated font and appearance objects follow the original document encryption policy, whilst the original source prefix and earlier signatures remain intact for permitted incremental signing
Seed requirements and limits
A required SV AppearanceFilter matches only the preset actually generated in this signing operation; existing metadata or a previously saved appearance does not satisfy that requirement by itself
The AP dictionary records HotPDFProfile for inspection, whilst the successful result reports appearanceProfile; both describe the preset used by this operation
Font bytes are capped at the smaller of 8 MiB and one eighth of memoryBytes, generated appearance bytes share a cap of one eighth of memoryBytes, and each Widget adds seven bounded objects subject to objectCount
Cancellation, invalid presets, unmet required seeds, and invalid generation preserve the original document handle and publish no PDF bytes; output callbacks retain the existing callback failure semantics
Combine appearance with actual signing timestamps, certification and legal attestation, or authenticated signed revocation information
See Incremental PFX Signing for the operation lifecycle, permissions, budgets, and publication contract