C ABI nativa de Linux

HotPDFLinuxABI.lpr compila 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 componente de Windows, escritorio activo, visor de PDF ni proceso Python en runtime; Python lo usan los scripts de build y 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.sh

Use FPC 3.3.1 nativo o posterior con unidades FCL y paszlib coincidentes, un compilador de C, binutils, Fontconfig y fuentes TrueType instaladas; el entorno Python de aceptación también necesita pypdf con su proveedor AES, PyMuPDF, Pillow y NumPy

FPC_EXE, HPDF_LINUX_OUTPUT y PYTHON_EXE seleccionan las ubicaciones de herramientas; el entorno Python de aceptación por defecto es /opt/hotpdf-python/bin/python

FPC normalmente escribe un bloque de exportación anónimo en su respuesta del linker ELF; el build nombra ese bloque usando el symbol map versionado del repositorio antes de linkear, porque agregar un segundo version script nombrado entraría en conflicto con el bloque anónimo

Interfaz pública

Incluye Lib/hotpdf_abi.h para el layout compartido de records y las constantes de status; hpdf_abi_io_v1_size y hpdf_abi_operation_v1_size reportan los tamaños nativos reales de los records

La biblioteca de Linux exporta discovery de la ABI, discovery de capacidades, creación y destrucción de documentos, carga y guardado por callbacks, conteo de páginas, hpdf_document_execute_json_v1 y el punto de entrada de dos documentos hpdf_document_compare_json_v1

Descubre las operaciones actuales mediante hpdf_capabilities_json_to_io en lugar de asumir el set de operaciones de Windows

{"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 exitosa 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, información de firma Unicode, attestation legal, bytes de trust explícitos, evidencia de revocación firmada validada, presets reales de apariencia y provenance de transporte de credenciales o timestamps declarado por la aplicación

El estado de visor de optional-content opcional suministra aplicaciones explícitas automáticas de uso View, Print o Export, zoom, idioma, contexto de usuario y selecciones manuales locales de la operación mediante records V1 sin cambios

La operación render acepta usage: "view" o usage: "print", con view por defecto; descubre las opciones mediante el array de capacidades renderUsages, con records V1 de callback y operación sin cambios

Los flags de pantalla e impresión de anotaciones siguen el uso seleccionado, y annotations: false suprime las anotaciones en cualquier modo; omitir optionalContent retiene la configuración predeterminada 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 fuentes planas y AES R5/R6, contenido desactivado por defecto, fallos de callbacks, presupuestos, cancelación y recuperación con el mismo handle; consulta Tests/Linux/HeadlessRenderUsage.en-us.md para las dependencias de fixtures y el directorio opcional de fixtures pregenerados

Callbacks y lifetime

Las opciones de apariencias de formularios aceptan texto Unicode, export values o arrays de selección completos, estados de botones explícitos, ajustes de fuentes y límites transaccionales de recursos

Los callbacks de lectura y escritura pueden devolver transferencias parciales; las transferencias exitosas deben avanzar de forma positiva y no exceder el conteo solicitado

Todos los callbacks se ejecutan de forma síncrona en el thread llamante, incluidas las comprobaciones de cancelación dentro de los checkpoints de parseo de documentos, rendering y criptografía

La entrada de callbacks se copia a un archivo temporal privado creado en exclusiva con mode 0600, así que los callbacks de entrada de Linux y sus user data solo necesitan seguir válidos hasta que la llamada de load o execute 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 los lookups posteriores mientras permite que la llamada actual termine de forma segura

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 cada handle haya sido destruido

Presupuestos y publicación

La entrada JSON se limita a 4 MiB y 64 niveles de anidación, y rechaza UTF-8 inválido, miembros duplicados, límites numéricos malformados y truncamiento de parámetros de Int64 a Int32

El UTF-8 raw y los escapes Unicode cargan los mismos valores de cadena, incluidos los caracteres suplementarios representados por pares surrogate UTF-16 válidos; los escapes surrogate no emparejados fallan antes de la mutación del documento o la publicación binaria

Los límites de operación incluyen memoryBytes, outputBytes, resultBytes y pixels; los límites de documento también se aplican a handles cargados previamente, mientras que la memoria administrada y los límites de rendering no prometen un tope de RSS del 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 caller puede retener una transferencia parcial tras su propio fallo de I/O, pero la publicación binaria o de resultado fallida no confirma ediciones de formularios ni reemplaza un contexto previamente cargado

Las mutaciones PDF exitosas confirman la salida preparada tanto como documento actual como snapshot privado de su fuente, de modo que una importación FDF o XFDF posterior del mismo valor devuelve los bytes PDF confirmados exactos con updated=0, reteniendo los llenados de formularios previos, las apariencias rich tipadas, el texto dibujado y las páginas importadas

Los archivos de staging privados se eliminan cuando el contexto se reemplaza o destruye; la salida incremental exitosa de formularios y firmas preserva el prefijo de fuente original y la política de cifrado

Evidencia

La reparación opcional de fuentes para archivado activa sustitución e incrustación acotadas con Ghostscript y validación PDF/A-4 genuina antes de los callbacks

El PDF de revisión anotado nativo agrega salida PDF preparada real, highlights Unicode y permisos autenticados de anotaciones P3 a la comparación semántica

La comparación nativa de contratos provee comparación semántica acotada de dos handles, HTML de revisión Unicode y geometría real de líneas fuente

La comparación nativa general de documentos normaliza object graphs y codificación de streams, compara píxeles reales de Cairo con thresholds 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 C y lookup versionado de símbolos, callbacks parciales, 80 operaciones concurrentes con handles compartidos, 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 security dictionaries, los document IDs, los gaps exactos de ByteRange, las firmas válidas y el rechazo de bytes firmados modificados

API de documentos headless · rendering nativo · Plan de entrega restante