C ABI nativo de Linux
HotPDFLinuxABI.lpr construye una biblioteca compartida ELF x86_64 nativa llamada libhotpdf.so.1, con SONAME libhotpdf.so.1 y símbolos públicos asignados a HOTPDF_1.0
La biblioteca usa THPDFHeadlessDocument y rendering por CPU sin ningún componente de Windows, escritorio activo, visor de PDF ni proceso Python en runtime; Python lo usan los scripts de build y de aceptación
Build y aceptación
sh Tests/Linux/Build-LinuxABI.sh
sh Tests/Linux/Run-LinuxABIAcceptance.sh
FPC_EXE=/usr/local/bin/fpc HPDF_LINUX_OUTPUT=Tests/Linux/bin/linux-abi331 sh Tests/Linux/Run-LinuxABIAcceptance.shUsa FPC nativo 3.2.2 o más nuevo con FCL y paszlib, un compilador de C, binutils, Fontconfig y fuentes TrueType instaladas; el entorno Python de aceptación necesita además pypdf con su proveedor AES, PyMuPDF, Pillow y NumPy
FPC_EXE, HPDF_LINUX_OUTPUT y PYTHON_EXE seleccionan las ubicaciones de las herramientas; el entorno Python de aceptación por defecto es /opt/hotpdf-python/bin/python
FPC normalmente escribe un bloque de export anónimo en su respuesta del enlazador ELF; el build asigna nombre a ese bloque usando el mapa de símbolos del repositorio antes de enlazar, porque añadir un segundo version script con nombre entraría en conflicto con el bloque anónimo
Interfaz pública
Incluye Lib/hotpdf_abi.h para el layout compartido de registros y las constantes de estado; hpdf_abi_io_v1_size y hpdf_abi_operation_v1_size informan de los tamaños nativos reales de los registros
La biblioteca de Linux exporta descubrimiento del ABI, descubrimiento de capacidades, creación y destrucción de documentos, carga y guardado por callback, recuento de páginas, hpdf_document_execute_json_v1 y el punto de entrada de comparación de dos documentos hpdf_document_compare_json_v1
Descubre las operaciones actuales mediante hpdf_capabilities_json_to_io en lugar de asumir el conjunto de operaciones de Windows
| Operación | Comportamiento |
|---|---|
info | Recuentos de páginas, formularios y campos firmados |
text.extract | Texto Unicode de página en JSON y salida UTF-8 opcional, con un array de páginas opcional basado en cero |
forms.read | Nombres de campo totalmente cualificados, valores Unicode, selecciones de choice completas, tipos, flags y longitudes máximas |
forms.fill | Actualizaciones transaccionales de texto, choice, multiselect, checkbox y radio, captions de push-button, apariencias con fuentes incrustadas coincidentes y salida PDF incremental |
annotations.export / annotations.import | Intercambio acotado de anotaciones XFDF con transacciones de añadido, Unicode exacto, streams binarios, referencias popup/reply, cifrado y política de certificación autenticada |
forms.export / forms.import | Intercambio acotado escalar y rich de FDF/XFDF con cuatro estilos reales por familia rich configurada, transacciones de PDF cifrado, apariencias regeneradas, políticas de firma y callbacks síncronos fragmentados |
render | Salida PNG por Cairo con página, dpi, uso view o print, opciones de anotaciones y la configuración por defecto de optional content |
sign | Firma incremental PEM o PFX, campos existentes o recién creados, apariencias visibles y certificación, incluidas entradas autenticadas AES-256 R5/R6 y opciones de digest, metadatos, perfil y evidencia validada |
signatures.verify | Verificación CMS real, longitudes de revisiones firmadas, evaluación opcional de confianza CA explícita y validación de información de revocación firmada |
html.import | Creación nativa de documentos HTML/CSS con fuentes Unicode, paginación, imágenes, hipervínculos y controles AcroForm opcionales |
text.draw | Texto Unicode de página visible o invisible con streams de página originales preservados y revisiones cifradas autenticadas |
ocr | Reconocimiento Tesseract real con vida útil acotada del proceso hijo, resultados por palabra y una capa PDF buscable opcional |
pages.import | Importaciones de recursos de páginas seleccionadas con entrada de origen independiente y actualizaciones transaccionales del destino |
pdfa.convert | Conversión ráster o texto/vector a PDF/A-4, con reparación de fuentes opcional y los requisitos de validación del modo seleccionado |
compare / compare.contract | Comparación de dos handles por recuento de páginas, texto de página, recuento de objetos, imagen renderizada, estructural y completa, más comparación semántica de contratos con salida de revisión JSON, HTML o PDF anotado preparada |
{"schemaVersion":1,"type":"render","page":0,"dpi":150,"usage":"print","annotations":false,
"limits":{"memoryBytes":268435456,"outputBytes":268435456,"pixels":100000000}}Los workflows nativos de firma aceptan una identidad explícita PEM o PFX Base64, campos de firma nuevos opcionales y apariencias Unicode, y permisos de certificación; una firma con éxito reemplaza el contexto cargado por la revisión firmada preparada, mientras que una firma o publicación fallida preserva el contexto original
Las opciones nativas de firma vinculan la selección real de SHA256, SHA384 o SHA512, la información de firma Unicode, la attestation legal, los bytes de confianza explícitos, la evidencia firmada de revocación validada, los presets reales de apariencia y la procedencia de transporte de credenciales o timestamps afirmada por la aplicación
El estado de visor de optional content opcional aporta aplicaciones de uso automáticas explícitas de View, Print o Export, zoom, idioma, contexto de usuario y selecciones manuales locales de la operación mediante registros V1 intactos
La operación render acepta usage: "view" o usage: "print", con view por defecto; descubre las opciones mediante el array de capacidades renderUsages, con registros V1 de callback y de operación intactos
Los flags de anotaciones de pantalla e impresión siguen el uso seleccionado, y annotations: false suprime las anotaciones en ambos modos; omitir optionalContent retiene la configuración por defecto estática, mientras que un objeto explícito activa las recomendaciones automáticas documentadas y las selecciones manuales locales de la operación
Tests/Linux/Run-LinuxABIRenderUsage.sh verifica píxeles PNG reales para orígenes planos y AES R5/R6, contenido desactivado por defecto, fallos de callback, presupuestos, cancelación y recuperación con el mismo handle; consulta Tests/Linux/HeadlessRenderUsage.en-us.md para las dependencias de los fixtures y el directorio de fixtures pregenerado opcional
Callbacks y ciclo de vida
Las opciones de apariencia de formularios aceptan texto Unicode, export values o arrays de selección completos, estados de botón explícitos, ajustes de fuente y límites transaccionales de recursos
Los callbacks de lectura y escritura pueden devolver transferencias parciales; las transferencias con éxito deben progresar de forma positiva y no deben exceder el recuento solicitado
Todos los callbacks se ejecutan de forma síncrona en el hilo llamador, incluidas las comprobaciones de cancelación dentro de los checkpoints de análisis del documento, rendering y criptografía
La entrada de callback se copia a un fichero temporal privado de creación exclusiva con modo 0600, de modo que los callbacks de entrada de Linux y sus datos de usuario solo necesitan seguir válidos hasta que la llamada de carga o ejecución devuelva
Las operaciones sobre un handle de documento compartido se serializan internamente; cada llamada activa retiene una referencia independiente, de modo que destruir un handle desde un callback de progreso invalida las búsquedas posteriores mientras permite que la llamada actual termine con seguridad
No ejecutes recursivamente otra operación sobre el mismo handle desde su callback; mantén cargada la biblioteca compartida hasta que todas las llamadas hayan devuelto y todos los handles se hayan destruido
Presupuestos y publicación
La entrada JSON se limita a 4 MiB y 64 niveles de anidamiento, y rechaza UTF-8 inválido, miembros duplicados, límites numéricos malformados y el truncamiento de parámetros de Int64 a Int32
El UTF-8 bruto y los escapes Unicode portan los mismos valores de cadena, incluidos los caracteres suplementarios representados por pares surrogados UTF-16 válidos; los escapes de surrogados no emparejados fallan antes de la mutación del documento o de la publicación binaria
Los límites de operación incluyen memoryBytes, outputBytes, resultBytes y pixels; los límites de documento también aplican a los handles previamente cargados, mientras que la memoria gestionada y los límites de rendering no prometen un techo de RSS de proceso
La salida PDF y PNG se prepara y comprueba por completo antes de que empiecen los callbacks de salida; un callback de salida propio del llamador puede retener una transferencia parcial tras su propio fallo de I/O, pero una publicación binaria o de resultado fallida no confirma ediciones de formulario ni reemplaza un contexto previamente cargado
Las mutaciones PDF con éxito confirman la salida preparada tanto como documento actual como snapshot privado de origen, de modo que una importación FDF o XFDF posterior con el mismo valor devuelve los bytes PDF confirmados exactos con updated=0, reteniendo los rellenos de formulario anteriores, las apariencias rich tipadas, el texto dibujado y las páginas importadas
Los ficheros de staging privados se eliminan cuando el contexto se reemplaza o destruye; la salida incremental de formularios y firmas con éxito preserva el prefijo de origen original y la política de cifrado
Evidencia
La reparación de fuentes de archivado opcional habilita sustitución e incrustación acotadas con Ghostscript y validación genuina de PDF/A-4 antes de los callbacks
El PDF de revisión anotado nativo añade a la comparación semántica salida PDF preparada real, resaltados Unicode y permisos de anotación P3 autenticados
La comparación nativa de contratos proporciona comparación semántica acotada de dos handles, HTML de revisión Unicode y geometría real de líneas de origen
La comparación nativa general de documentos normaliza los grafos de objetos y la codificación de streams, compara píxeles reales de Cairo con umbrales explícitos y preserva el estado del documento y los presupuestos de publicación por callback
El cliente de aceptación verifica layouts reales de headers de C y búsqueda de símbolos versionada, callbacks parciales, 80 operaciones concurrentes con handle compartido, cancelación, ediciones Unicode, rollback y firma cifrada
Los lectores independientes pypdf, MuPDF y OpenSSL verifican los PDFs reales, los píxeles PNG, los passwords retenidos, los diccionarios de seguridad, los IDs de documento, los huecos ByteRange exactos, las firmas válidas y el rechazo de los bytes firmados modificados
API de documento headless · Rendering nativo · Plan de entrega restante