Intercambio FDF/XFDF en Windows

Los trabajos de fichero de Windows y hpdf_document_execute_json_v1 implementan forms.export y forms.import para fdf y xfdf usando los codecs nativos escalares y de XHTML/CSS rich acotado

Trabajos de fichero

{
  "schemaVersion": 1, "type": "forms.import", "format": "xfdf",
  "input": "source.pdf", "output": "filled.pdf", "password": "owner",
  "formDataInput": "values.xfdf",
  "fonts": {
    "regular": "DejaVuSans.ttf", "bold": "DejaVuSans-Bold.ttf",
    "italic": "DejaVuSans-Oblique.ttf", "boldItalic": "DejaVuSans-BoldOblique.ttf"
  },
  "budget": {"memoryBytes": 268435456, "outputBytes": 134217728,
    "timeMilliseconds": 60000, "resultBytes": 16777216}
}

forms.export usa input, output, format y un password opcional; no necesita formDataInput ni fonts; los trabajos de fichero reservan un candidato exclusivo junto al destino, lo vuelcan y lo cierran, validan el JSON de resultado acotado y después reemplazan el destino atómicamente

Fuentes ausentes, entrada malformada, fallos de autenticación o de política, límites agotados y publicación fallida preservan el destino completo existente; la salida no debe ser alias del PDF ni de la entrada de datos de formulario, incluido un hard link

Familias de fuentes con nombre

forms.import acepta fontFamilies en la raíz de la operación como un array de una a dieciséis etiquetas; su ausencia retiene el perfil original de familia única y la etiqueta del callback fontFamily

"fontFamilies": ["DejaVu Sans", "DejaVu Serif Condensed"],
"fonts": {
  "DejaVu Sans": {
    "regular": "DejaVuSans.ttf", "bold": "DejaVuSans-Bold.ttf",
    "italic": "DejaVuSans-Oblique.ttf", "boldItalic": "DejaVuSans-BoldOblique.ttf"
  },
  "DejaVu Serif Condensed": {
    "regular": "DejaVuSerifCondensed.ttf", "bold": "DejaVuSerifCondensed-Bold.ttf",
    "italic": "DejaVuSerifCondensed-Italic.ttf", "boldItalic": "DejaVuSerifCondensed-BoldItalic.ttf"
  }
}

En los trabajos de fichero, fonts contiene objetos indexados por las etiquetas configuradas exactas; sin fontFamilies se retiene el objeto original de rutas directas por estilo; se leen solo los programas reales de familia/estilo, con todos los bytes de fuente seleccionados compartiendo el presupuesto de la operación

Para los callbacks V1 de Windows, el callback de fuente existente recibe cada etiqueta configurada UTF-8 canónica real y el estilo seleccionado; dos familias que usan los cuatro estilos generan ocho peticiones reales de programas sin cambiar el registro del callback

Las letras ASCII de las etiquetas se comparan sin distinguir mayúsculas mientras que los demás caracteres Unicode se comparan de forma exacta; las etiquetas son distintas, no vacías y de 128 unidades de código UTF-16 como máximo, sin espacios en blanco circundantes, controles, surrogados no emparejados ni puntuación de comillas/separadores CSS

La primera familia configurada es la de por defecto para el texto escalar y los estilos rich heredados; por defecto, las listas CSS font-family usan la selección de primera familia conocida del codec nativo

El fallback opt-in fallbackFontFamilies=true preserva los candidatos CSS font-family inline ordenados y carga los programas reales de cara/estilo configurados para el fallback de grafema completo; consulta fallback rich de fuentes por familia suministrada en Windows para los candidatos tipados, la carga por callback y el alcance exclusivo rich

El resultado aplicado informa de richXMLProfile inline-xhtml-font-families-v1, del array fontFamilies configurado y de objetos fontFamilyStyles reales con family, style y bytes; fontStyles conserva su tipo original de array de objetos y resume los recuentos de bytes por estilo; fontBytes cuenta todos los programas reales

Sin el array, richXMLProfile es inline-xhtml-v1; el forms.fill mixto escalar y rich con tipos originales usa el binding separate original-typed-runs-v1 descrito más abajo; la extensión más antigua del callback de fuente de trabajos sigue siendo un trabajo posterior independiente

Callbacks versionados de C para Windows

Incluye hotpdf_abi_form_data.h; rellena hpdf_form_data_operation_v1, pon operation.struct_size a su tamaño completo y pasa su prefijo de operación intacto a hpdf_document_execute_json_v1

El callback de fuente opcional recibe los bytes UTF-8 de la familia y el estilo 0 regular, 1 bold, 2 italic o 3 boldItalic, y devuelve una tabla de lectura hpdf_io_v1 completa del programa de fuente real; aporta los cuatro programas cuando los datos rich usan los cuatro estilos

Los datos escalares piden el programa regular; fontFamily es DejaVu Sans por defecto; los callbacks IO de fuente suministrados y sus datos de usuario deben seguir válidos hasta que la operación devuelva; los estados de callback distintos de cero son sticky y se propagan sin reintento con fallback

Para forms.import, InputIO aporta el FDF/XFDF y el destino debe estar ya cargado; OutputIO recibe el PDF candidato y ResultIO recibe el JSON acotado; forms.export usa el registro V1 original y escribe el FDF/XFDF en OutputIO

Windows hpdf_document_load_from_io copia la entrada completa a un origen propio inmutable antes de devolver; el reemplazo o la adición por parte del llamador no pueden cambiar la revisión cargada activa ni su posterior salida de datos de formulario

Los orígenes propios usan un handle separado y sincronizado para lecturas aleatorias en segundo plano, de modo que el prefetch no puede mover el cursor de publicación secuencial; el documento candidato libera sus lectores en segundo plano antes de que su origen se destruya

El contexto activo cambia solo cuando los callbacks de salida y de resultado tienen éxito y el checkpoint final de cancelación pasa; un fallo o la cancelación del callback descartan el candidato y retienen el documento y el origen propios anteriores

Un callback puede haber recibido bytes del candidato antes de que un callback posterior falle; los llamadores deben confirmar su propio destino de salida solo después de que la función de ejecución devuelva HPDF_STATUS_OK

Los layouts de registros V1 originales y los símbolos exportados no cambian; esta extensión de Windows es independiente de la extensión de callbacks publicada del Linux nativo

Los puntos de entrada vinculados son el procesador de trabajos de fichero y hpdf_document_execute_json_v1; el registro de callback más antiguo de HPDFDocRunJob y el ExecuteLoadedOperation genérico no adquieren una extensión de fuente en esta fase; los llamadores Pascal pueden usar la clase de transacción explícita

Campos, texto rich y política

Los valores soportados incluyen nombres Unicode anidados, nombres de export de checkbox y radio, arrays multiselect y valores de solo lectura intactos; /V, /RV y los recursos AP genuinos se guardan juntos; los campos desconocidos y las restricciones de campos obligatorios hacen fallar la transacción

El intercambio rich usa el perfil XHTML/CSS acotado documentado y fuentes de estilo reales suministradas; no reclama soporte de HTML arbitrario, de todo el CSS ni de XML rich sin restricciones

Las actualizaciones firmadas AES R5/R6 retienen el prefijo original completo, los parámetros de cifrado, el identificador permanente de cifrado y la firma CMS existente; las importaciones escalares o rich sin cambios son byte-idénticas a la revisión confirmada actual

La integridad CMS existente y el binding ESS del firmante se autentican antes de las actualizaciones de formularios firmados; el relleno P2/P3 solo se permite dentro de sus restricciones reales; P1, los bloqueos FieldMDP y los campos de solo lectura modificados rechazan la publicación

signaturePolicy acepta los booleanos requireCAdES, requireTimestamp, requireAdobeRevocationInfo y requireTimestampRevocation; trustedCAFile, timestampCAFile, timestampCRLFile y revocationCAFile deben ser cadenas sin NUL y seleccionan la confianza explícita del llamador para las comprobaciones solicitadas

Las opciones del callback de C también acotan la evidencia firmada mediante maxEvidenceBytes y maxEvidenceObjects; la validación de confianza es distinta de la comprobación por defecto de integridad de firmas

formData puede rebajar maxBytes, maxFields, maxObjects, maxDepth, maxValues, maxValueCodeUnits y maxTotalCodeUnits; estos enteros positivos exactos se recortan además por la capacidad de trabajo; los budget objectCount y pageCount limitan los documentos candidatos

budget.timeMilliseconds fija el deadline de la operación; los callbacks de C de Windows aceptan además elapsedMilliseconds como un límite adicional más estricto; la cancelación se sondea durante la preparación del grafo actual, la decodificación del formulario, la lectura de fuentes, las comprobaciones CMS, la carga del candidato y la publicación

Las capacidades informan de los formatos, estilos, entrada inmutable y comportamiento transaccional de callbacks reales; el intercambio de anotaciones, los ficheros FDF incrustados, las actions y los documentos FDF incrementales siguen siendo capacidades separadas sin terminar

Temas relacionados

El relleno mixto escalar y rich con tipos originales usa el mismo ciclo de vida de candidato Windows autenticado mediante trabajos de fichero y execute-json-v1

Clase de transacción, Preparación del grafo actual, Datos de formulario nativos

Las style sheets internas aplican selectores acotados, importancia, especificidad y orden de fuente a los rich values importados reales y a las appearances guardadas; las importaciones equivalentes repetidas y la publicación fallida retienen las garantías transaccionales existentes

richTextResources suministra CSS enlazado e importado para los file jobs reales de Windows y las importaciones execute-json-v1, usando la transacción y los enlaces de fuentes existentes