C ABI su Linux nativo

HotPDFLinuxABI.lpr compila una shared library ELF nativa x86_64 denominata libhotpdf.so.1, con SONAME libhotpdf.so.1 e simboli pubblici assegnati a HOTPDF_1.0

La libreria usa THPDFHeadlessDocument e rendering CPU senza componenti Windows, desktop attivo, lettori PDF o processi Python a runtime; Python è usato dagli script di build e accettazione

Build e accettazione

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

Usate FPC nativo 3.3.1 o superiore con unità FCL e paszlib corrispondenti, un compilatore C, binutils, Fontconfig e font TrueType installati; l'ambiente Python di acceptance necessita anche di pypdf con il suo provider AES, PyMuPDF, Pillow e NumPy

FPC_EXE, HPDF_LINUX_OUTPUT e PYTHON_EXE selezionano le posizioni dei tool; l'ambiente Python di accettazione default è /opt/hotpdf-python/bin/python

FPC scrive normalmente un blocco export anonimo nella propria risposta del linker ELF; la build nomina quel blocco usando la symbol map tracciata nel repository prima del linking, perché aggiungere una seconda version script nominata andrebbe in conflitto con il blocco anonimo

Interfaccia pubblica

Includete Lib/hotpdf_abi.h per il layout condiviso dei record e le costanti di stato; hpdf_abi_io_v1_size e hpdf_abi_operation_v1_size riportano le reali dimensioni native dei record

La libreria Linux esporta discovery ABI, discovery delle capability, creazione e distruzione di documenti, caricamento e salvataggio via callback, conteggio pagine, hpdf_document_execute_json_v1 e il punto di ingresso hpdf_document_compare_json_v1 a due documenti

Scoprite le operazioni correnti tramite hpdf_capabilities_json_to_io invece di dare per scontato l'insieme di operazioni Windows

{"schemaVersion":1,"type":"render","page":0,"dpi":150,"usage":"print","annotations":false,
 "limits":{"memoryBytes":268435456,"outputBytes":268435456,"pixels":100000000}}

Workflow di firma nativi accettano un'identità PEM o PFX Base64 esplicita, campi firma nuovi opzionali e appearance Unicode, oltre a permessi di certificazione; una firma riuscita sostituisce il contesto caricato con la revisione firmata preparata, mentre una firma o pubblicazione fallita preserva il contesto originale

Opzioni di firma native vincolano la selezione reale SHA256, SHA384 o SHA512, informazioni firma Unicode, attestazione legale, byte di trust espliciti, evidenza di revoca firmata validata, preset appearance reali e provenienza del trasporto di credenziali o timestamp dichiarata dall'applicazione

Lo stato viewer optional-content opzionale fornisce applicazioni d'uso automatiche esplicite View, Print o Export, zoom, lingua, contesto utente e selezioni manuali locali all'operazione tramite record V1 invariati

L'operazione render accetta usage: "view" o usage: "print", con default view; scoprite le scelte tramite l'array renderUsages delle capability, con record callback e operazione V1 invariati

I flag screen e print delle annotazioni seguono l'uso selezionato, e annotations: false sopprime le annotazioni in entrambe le modalità; omettere optionalContent conserva la configurazione predefinita statica, mentre un oggetto esplicito attiva le raccomandazioni automatiche documentate e le selezioni manuali locali dell'operazione

Tests/Linux/Run-LinuxABIRenderUsage.sh verifica pixel PNG reali per sorgenti semplici e AES R5/R6, contenuto default-off, fallimenti callback, budget, cancellazione e recupero dello stesso handle; vedere Tests/Linux/HeadlessRenderUsage.en-us.md per le dipendenze dei fixture e la directory di fixture pre-generata opzionale

Callback e ciclo di vita

Opzioni degli appearance dei form accettano testo Unicode, export value o array di selezione completi, stati espliciti dei bottoni, impostazioni font e limiti transazionali delle risorse

I callback di lettura e scrittura possono restituire trasferimenti parziali; i trasferimenti riusciti devono fare progresso positivo e non devono superare il conteggio richiesto

Tutti i callback si eseguono sincronamente sul thread chiamante, inclusi i controlli di cancellazione dentro parsing del documento, rendering e checkpoint crittografici

L'input dei callback viene copiato in un file temporaneo privato creato in modo esclusivo con modalità 0600, così i callback di input Linux e i relativi user data devono restare validi solo finché la chiamata load o execute non restituisce

Le operazioni su un handle documento condiviso si serializzano internamente; ogni chiamata attiva trattiene un riferimento indipendente, quindi distruggere un handle da un callback di progresso invalida i lookup successivi consentendo alla chiamata corrente di concludersi in sicurezza

Non eseguite ricorsivamente un'altra operazione sullo stesso handle dal suo callback; tenete la shared library caricata finché tutte le chiamate non sono restituite e ogni handle non è stato distrutto

Budget e pubblicazione

L'input JSON è limitato a 4 MiB e 64 livelli di nesting, e rifiuta UTF-8 non valido, membri duplicati, limiti numerici malformati e troncamenti di parametri Int64 a Int32

Gli escape UTF-8 raw e Unicode portano gli stessi valori stringa, inclusi i caratteri supplementari rappresentati da surrogate pair UTF-16 valide; gli escape surrogate non appaiati falliscono prima della mutazione del documento o della pubblicazione binaria

I limiti delle operazioni includono memoryBytes, outputBytes, resultBytes e pixels; i limiti del documento si applicano anche agli handle caricati in precedenza, mentre memoria gestita e limiti di rendering non garantiscono un tetto sul RSS del processo

L'output PDF e PNG viene completamente preparato e controllato prima che inizino gli output callback; un output callback di proprietà del chiamante può trattenere un trasferimento parziale dopo un proprio fallimento I/O, ma la pubblicazione binaria o di risultato fallita non committa modifiche al form né sostituisce un contesto caricato in precedenza

Le mutazioni PDF riuscite committano l'output preparato sia come documento corrente sia come snapshot sorgente privato, così un successivo import FDF o XFDF con gli stessi valori restituisce gli esatti byte PDF committati con updated=0, trattenendo i fill precedenti, gli appearance rich tipizzati, il testo disegnato e le pagine importate

Gli staging file privati vengono rimossi quando il contesto viene sostituito o distrutto; l'output incrementale riuscito di form e firma preserva il prefisso sorgente originale e la policy di cifratura

Evidenze

Riparazione font archivistica opzionale abilita sostituzione ed embedding Ghostscript limitati con validazione PDF/A-4 genuina prima dei callback

PDF di revisione annotato nativo aggiunge output PDF preparato reale, highlight Unicode e permessi di annotazione P3 autenticati al confronto semantico

Confronto contrattuale nativo fornisce confronto semantico limitato a due handle, HTML di revisione Unicode e geometria reale delle righe sorgente

Confronto documenti nativo generale normalizza grafi di oggetti ed encoding degli stream, confronta pixel Cairo reali con soglie esplicite e preserva lo stato dei documenti e i budget di pubblicazione via callback

Il client di accettazione verifica layout reali degli header C e lookup di simboli versionati, callback parziali, 80 operazioni concorrenti su handle condivisi, cancellazione, modifiche Unicode, rollback e firma cifrata

I reader indipendenti pypdf, MuPDF e OpenSSL verificano i PDF reali, i pixel PNG, le password trattenute, i dizionari di sicurezza, gli ID documento, i gap ByteRange esatti, le firme valide e il rifiuto dei byte firmati modificati

API documentale headless · Rendering nativo · Piano di consegne rimanenti