Windows-Signatur-Appearance-Profile

Die Windows-sign-Operation kann eine sichtbare Unicode-Signatur-Appearance aus einem benannten eingebauten Preset und einer explizit gelieferten einbettbaren TrueType-Schrift erzeugen

{"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"}}

Echte Preset-Auswahl

profileNameErzeugte Konfiguration
HotPDF.StandardApproval11 pt zentrierter blauer Text, 4 pt Padding, ein Rechteckrahmen, ein weißer Hintergrund und eine einzelne Textzeile
HotPDF.StandardCertification10 pt linksbündiger schwarzer Text, 5 pt Padding, ein Rechteckrahmen, ein weißer Hintergrund, mehrzeiliger Umbruch und 1.35 Zeilenabstand
HotPDF.Compact8 pt rechtsbündiger schwarzer Text, 1 pt Padding, kein gemalter Hintergrund oder Rahmen und eine einzelne Textzeile

Das gewählte Preset konfiguriert den tatsächlichen Producer, statt vom Aufrufer definierte visuelle Optionen zu labeln; dies sind dieselben Konfigurationen, die HPDFSelectHeadlessSignatureAppearanceProfile zurückgibt

text liefert die tatsächliche Caption, und fontFile liefert ihr TrueType-Programm; beide sind erforderliche, nichtleere Unicode-Strings, und alle drei Appearance-Strings sind auf 16,384 UTF-8-Bytes ohne NUL begrenzt

Font-Einbettungsberechtigungen, Unicode-Gültigkeit, verfügbare Glyphen, komplexe Shaping-Anforderungen, Caption-Passung und konfigurierte Limits werden während der Generierung durchgesetzt

Widgets und signierte Dokumente

Die Generierung aktualisiert das normale AP/N-Form XObject für jedes Widget, das zum gewählten Signaturfeld gehört, einschließlich zusammengeführter Felder und Felder mit separaten Widget-Kindern

Jedes Widget liefert seine eigenen positiven Rechteckdimensionen und optionale MK/R-Rotation von 0, 90, 180 oder 270 Grad; Preset-Ausrichtung hat Vorrang vor geerbten Ausrichtungshinweisen

Rollover- und Down-Appearances bleiben erhalten, wenn ein bestehendes AP-Dictionary vorhanden ist; fehlerhafte Geometrie, Appearance-Dictionarys, Rotationen oder zyklische Widget-Hierarchien verwerfen die Generierung

Die sign-Operation unterstützt bestehende Felder, neue Felder, inkrementelle verschlüsselte Updates, das Signieren unsignierter Dokumente, erste Zertifizierungssignaturen und nachfolgende Approval-Signaturen, die P2 oder P3 und Feld-Lock-Policys erlauben

Nutze certificationPermission, um echtes Zertifizierungsverhalten zu wählen; allein die Wahl der StandardCertification-Appearance zertifiziert das Dokument nicht

Erzeugte Schrift- und Appearance-Objekte folgen der Verschlüsselungspolicy des Originaldokuments, während der originale Quellpräfix und frühere Signaturen für erlaubtes inkrementelles Signieren intakt bleiben

Seed-Anforderungen und Limits

Ein erforderlicher SV-AppearanceFilter passt nur zum Preset, das in dieser sign-Operation tatsächlich erzeugt wurde; bestehende Metadaten oder eine zuvor gespeicherte Appearance erfüllen diese Anforderung nicht für sich

Das AP-Dictionary zeichnet HotPDFProfile zur Inspektion auf, und das erfolgreiche Ergebnis meldet appearanceProfile; beide beschreiben das in dieser Operation genutzte Preset

Font-Bytes sind auf das kleinere von 8 MiB und einem Achtel von memoryBytes gedeckelt, erzeugte Appearance-Bytes teilen sich eine Deckelung von einem Achtel von memoryBytes, und jedes Widget fügt sieben begrenzte Objekte hinzu, unterworfen objectCount

Abbruch, ungültige Presets, nicht erfüllte erforderliche Seeds und ungültige Generierung bewahren das ursprüngliche Dokument-Handle und veröffentlichen keine PDF-Bytes; Output-Callbacks behalten die bestehenden Callback-Fehler-Semantiken

Kombiniere die appearance mit echten Signaturzeitstempeln, Zertifizierung und rechtlicher Attestierung oder authentifizierten signierten Revocation-Informationen

Siehe Incremental PFX Signing für den Operations-Lebenszyklus, Berechtigungen, Budgets und den Veröffentlichungs-Contract