Perfiles de apariencia de firmas en Windows

La operación sign de Windows puede generar una apariencia visible de firma Unicode a partir de un preset con nombre integrado y una fuente TrueType embebible suministrada explícitamente

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

Selección real de preset

profileNameConfiguración generada
HotPDF.StandardApprovalTexto azul centrado de 11 pt, padding de 4 pt, un borde rectangular, un fondo blanco y una única línea de texto
HotPDF.StandardCertificationTexto negro alineado a la izquierda de 10 pt, padding de 5 pt, un borde rectangular, un fondo blanco, wrapping multilínea y espaciado de línea de 1.35
HotPDF.CompactTexto negro alineado a la derecha de 8 pt, padding de 1 pt, sin fondo ni borde pintados y una única línea de texto

El preset seleccionado configura el productor real en lugar de etiquetar opciones visuales definidas por el llamador; estas son las mismas configuraciones que devuelve HPDFSelectHeadlessSignatureAppearanceProfile

text suministra el caption real y fontFile suministra su programa TrueType; ambos son obligatorios, strings Unicode no vacíos, y los tres strings de apariencia se limitan a 16,384 bytes UTF-8 sin NUL

Los permisos de embebido de fuentes, la validez Unicode, los glifos disponibles, los requisitos de shaping complejo, el ajuste del caption y los límites configurados se aplican durante la generación

Widgets y documentos firmados

La generación actualiza el Form XObject normal AP/N de cada Widget perteneciente al campo de firma seleccionado, incluidos los campos combinados y los campos con hijos Widget separados

Cada Widget suministra sus propias dimensiones positivas de rectángulo y una rotación MK/R opcional de 0, 90, 180 o 270 grados; la alineación del preset toma precedencia sobre las pistas de alineación heredadas

Las apariencias rollover y down se preservan cuando existe un diccionario AP previo; la geometría malformada, los diccionarios de apariencia, las rotaciones o las jerarquías cíclicas de Widgets rechazan la generación

La operación de firma soporta campos existentes, campos nuevos, actualizaciones cifradas incrementales, firma de documentos sin firmar, primeras firmas de certificación y firmas de aprobación posteriores permitidas por P2 o P3 y las políticas de locks de campos

Usa certificationPermission para seleccionar el comportamiento real de certificación; elegir solo la apariencia StandardCertification no certifica el documento

Los objetos generados de fuentes y apariencias siguen la política original de cifrado del documento, mientras que el prefijo de origen original y las firmas anteriores permanecen intactos para la firma incremental permitida

Requisitos de seed y límites

Un AppearanceFilter de SV requerido coincide solo con el preset realmente generado en esta operación de firma; los metadatos existentes o una apariencia guardada previamente no satisfacen por sí solos ese requisito

El diccionario AP registra HotPDFProfile para inspección, mientras que el resultado exitoso reporta appearanceProfile; ambos describen el preset usado por esta operación

Los bytes de fuentes se acotan al menor entre 8 MiB y un octavo de memoryBytes, los bytes de apariencias generadas comparten un tope de un octavo de memoryBytes, y cada Widget agrega siete objetos acotados sujetos a objectCount

La cancelación, los presets inválidos, los seeds requeridos incumplidos y la generación inválida preservan el handle original del documento y no publican bytes de PDF; los callbacks de salida retienen la semántica existente de fallos de callbacks

Combina appearance con timestamps de firma reales, certificación y attestación legal, o información de revocación firmada autenticada

Consulta Firma incremental con PFX para el ciclo de vida de la operación, los permisos, los presupuestos y el contrato de publicación