Perfiles de apariencia de firmas en Windows
La operación de firma de Windows puede generar una apariencia de firma Unicode visible a partir de un preset con nombre incluido 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
| profileName | Configuración generada |
|---|---|
| HotPDF.StandardApproval | Texto azul centrado a 11 pt, padding de 4 pt, borde rectangular, fondo blanco y una sola línea de texto |
| HotPDF.StandardCertification | Texto negro alineado a la izquierda a 10 pt, padding de 5 pt, borde rectangular, fondo blanco, wrapping multilínea e interlineado de 1.35 |
| HotPDF.Compact | Texto negro alineado a la derecha a 8 pt, padding de 1 pt, sin fondo ni borde pintados y una sola línea de texto |
El preset seleccionado configura el producer 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, cadenas Unicode no vacías, y las tres cadenas de apariencia están limitadas 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 de AP/N normal para cada Widget perteneciente al campo de firma seleccionado, incluidos los campos fusionados 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 tiene prioridad sobre las pistas de alineación heredadas
Las apariencias rollover y down se preservan cuando existe un diccionario AP previo; la geometría mal formada, los diccionarios de apariencia, las rotaciones o las jerarquías de Widget cíclicas 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 las políticas P2 o P3 y de field locks
Usa certificationPermission para seleccionar el comportamiento real de certificación; elegir solo la apariencia StandardCertification no certifica el documento
Los objetos de fuentes y apariencias generados siguen la política de cifrado del documento original, mientras que el prefijo de la fuente original y las firmas anteriores permanecen intactos para la firma incremental permitida
Requisitos de seed y límites
Un AppearanceFilter SV obligatorio 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 correcto informa appearanceProfile; ambos describen el preset usado por esta operación
Los bytes de fuentes tienen un tope del 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 añade siete objetos acotados sujetos a objectCount
La cancelación, los presets inválidos, las seeds obligatorias no satisfechas y la generación inválida preservan el handle original del documento y no publican bytes de PDF; los callbacks de salida conservan la semántica de fallo de callbacks existente
Combina appearance con timestamps de firma reales, certificación y declaración legal, o información de revocación firmada autenticada
Consulta Incremental PFX Signing para el ciclo de vida de la operación, permisos, presupuestos y contrato de publicación