Native Linux C ABI

HotPDFLinuxABI.lpr baut eine native x86_64-ELF-Shared Library mit dem Namen libhotpdf.so.1, mit SONAME libhotpdf.so.1 und öffentlichen Symbolen unter HOTPDF_1.0

Die Bibliothek nutzt THPDFHeadlessDocument und CPU-Rendering ohne Windows-Komponente, aktiven Desktop, PDF-Viewer oder Python-Prozess zur Laufzeit; Python verwenden die Build- und Abnahmeskripte

Build und Abnahme

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

Verwenden Sie natives FPC 3.2.2 oder neuer mit FCL und paszlib, einen C-Compiler, binutils, Fontconfig und installierte TrueType-Schriften; die Python-Abnahmeumgebung braucht zudem pypdf mit seinem AES-Provider, PyMuPDF, Pillow und NumPy

FPC_EXE, HPDF_LINUX_OUTPUT und PYTHON_EXE wählen Werkzeugpfade; die Default-Python-Abnahmeumgebung ist /opt/hotpdf-python/bin/python

FPC schreibt normalerweise einen anonymen Exportblock in seine ELF-Linker-Antwort; der Build benennt diesen Block vor dem Linken über die eingecheckte Symbolmap, denn ein zweites benanntes Version-Skript würde mit dem anonymen Block kollidieren

Öffentliche Schnittstelle

Binden Sie Lib/hotpdf_abi.h für das gemeinsame Record-Layout und die Statuskonstanten ein; hpdf_abi_io_v1_size und hpdf_abi_operation_v1_size melden die tatsächlichen nativen Recordgrößen

Die Linux-Bibliothek exportiert ABI-Erkennung, Capability-Erkennung, Dokumenterzeugung und -zerstörung, Callback-Laden und -Speichern, Seitenzählung, hpdf_document_execute_json_v1 und den Zwei-Dokumente-Einstiegspunkt hpdf_document_compare_json_v1

Ermitteln Sie die aktuellen Operationen über hpdf_capabilities_json_to_io, statt das Windows-Operationset anzunehmen

Operation	Verhalten
`info`	Seiten-, Formular- und Signaturfeldzähler
`text.extract`	Unicode-Seitentext als JSON und optionale UTF-8-Ausgabe, mit optionalem nullbasiertem pages-Array
`forms.read`	Vollständig qualifizierte Feldnamen, Unicode-Werte, vollständige Choice-Auswahlen, Typen, Flags und Maximallängen
`forms.fill`	Transaktionale Text-, Choice-, Multiselect-, Checkbox- und Radio-Updates, Push-Button-Beschriftungen, passende Embedded-Font-Appearances und inkrementelle PDF-Ausgabe
`annotations.export` / `annotations.import`	Begrenzter Annotation-XFDF-Austausch mit Append-Transaktionen, eingebetteten Daten, Popup-Objekten und exakten No-ops
`forms.export` / `forms.import`	Begrenzter Skalar- und Rich-FDF/XFDF-Austausch mit vier echten Stilen pro gewählter konfigurierter Rich-Familie, verschlüsselten PDF-Transaktionen, neu erzeugten Appearances, Signaturpolicies und synchronen fragmentierten Callbacks
`render`	Cairo-PNG-Ausgabe mit Seite, dpi, View- oder Print-Verwendung, Annotationsoptionen und der Default-Optional-Content-Konfiguration
`sign`	Inkrementelles PEM- oder PFX-Signieren, vorhandene oder neu erzeugte Felder, sichtbare Appearances und Zertifizierung, einschließlich authentifizierter AES-256-R5/R6-Eingaben und Digest-, Metadaten-, Profil- und validierte Nachweis-Optionen
`signatures.verify`	Echte CMS-Verifikation, Längen signierter Revisionen, optionale explizite CA-Vertrauensbewertung und Validierung signierter Widerrufsinformationen
`html.import`	Native HTML/CSS-Dokumenterzeugung mit Unicode-Schriften, Paginierung, Bildern, Hyperlinks und optionalen AcroForm-Steuerelementen
`text.draw`	Sichtbarer oder unsichtbarer Unicode-Seitentext mit bewahrten originalen Seitenstreams und authentifizierten verschlüsselten Revisionen
`ocr`	Echte Tesseract-Erkennung mit begrenzter Kind-Lebensdauer, Arbeits- und Ausgabegrenzen sowie Such-PDF-Ausgabe über denselben Operation-Descriptor
`pages.import`	Importe ausgewählter Seitenressourcen mit unabhängiger Quell-Eingabe und validierter Ausgabe
`pdfa.convert`	Raster- oder Text-/Vektor-PDF/A-4-Konvertierung mit optionaler Schriftreparatur und VeraPDF-Stil-Validierung vor der atomaren Veröffentlichung
`compare` / `compare.contract`	Zwei-Handle-Vergleiche für Seitenzahl, Seitentext, Objektzahl, gerenderte Bilder, Struktur und vollständig, plus semantischer Vertragsvergleich mit aufbereiteter JSON-, HTML- oder annotierter PDF-Prüfausgabe

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

Native Signierworkflows akzeptieren eine explizite PEM- oder Base64-PFX-Identität, optionale neue Signaturfelder und Unicode-Appearances sowie Zertifizierungsberechtigungen; erfolgreiches Signieren ersetzt den geladenen Kontext durch die vorbereitete signierte Revision, während fehlgeschlagenes Signieren oder Veröffentlichen den ursprünglichen Kontext bewahrt

Native Signaturoptionen binden echte SHA256-, SHA384- oder SHA512-Auswahl, Unicode-Signaturinformationen, juristische Attestierung, explizite Trust-Bytes, validierte signierte Widerrufsnachweise, echte Appearance-Presets und von der Anwendung behauptete Credential- oder Timestamp-Transport-Herkunft

Der optionale Optional-Content-Viewer-Zustand liefert über unveränderte V1-Records explizite automatische View-, Print- oder Export-Usage-Applications, Zoom, Sprache, Benutzerkontext und operationslokale manuelle Auswahlen

Die Operation render akzeptiert usage: "view" oder usage: "print", Default ist view; die Auswahlmöglichkeiten ergeben sich über das Capability-Array renderUsages, mit unveränderten V1-Callback- und Operationsrecords

Die Annotation-Screen- und Print-Flags folgen der gewählten Verwendung, und annotations: false unterdrückt Annotationen in beiden Modi; das Weglassen von optionalContent behält die statische Default-Konfiguration bei, während ein explizites Objekt die dokumentierten automatischen Empfehlungen und operationslokale manuelle Auswahlen aktiviert

Tests/Linux/Run-LinuxABIRenderUsage.sh verifiziert echte PNG-Pixel für einfache und AES-R5/R6-Quellen, standardmäßig ausgeblendeten Inhalt, Callback-Fehler, Budgets, Abbruch und Same-Handle-Wiederherstellung; siehe Tests/Linux/HeadlessRenderUsage.en-us.md für Fixture-Abhängigkeiten und das optionale vorgenerierte Fixture-Verzeichnis

Callbacks und Lebensdauer

Formular-Appearance-Optionen akzeptieren Unicode-Text, Exportwerte oder vollständige Auswahlarrays, explizite Button-Zustände, Schrifteinstellungen und transaktionale Ressourcenlimits

Lese- und Schreib-Callbacks dürfen Teilübertragungen liefern; erfolgreiche Übertragungen müssen positiven Fortschritt machen und dürfen die angeforderte Anzahl nicht überschreiten

Alle Callbacks laufen synchron im aufrufenden Thread, einschließlich Abbruchprüfungen innerhalb der Dokumentparsung, des Renderings und der kryptografischen Checkpoints

Callback-Eingaben werden in eine exklusiv erzeugte private temporäre Datei mit Modus 0600 kopiert, daher müssen Linux-Eingabe-Callbacks und ihre User-Daten nur bis zur Rückkehr des Load- oder Execute-Aufrufs gültig bleiben

Operationen auf einem gemeinsamen Dokument-Handle serialisieren sich intern; jeder aktive Aufruf hält eine unabhängige Referenz, daher macht das Zerstören eines Handles aus einem Progress-Callback heraus nachfolgende Lookups ungültig, während der aktuelle Aufruf sicher zu Ende laufen kann

Führen Sie aus einem Callback heraus keine weitere Operation rekursiv auf demselben Handle aus; halten Sie die Shared Library geladen, bis alle Aufrufe zurückgekehrt und alle Handles zerstört sind

Budgets und Veröffentlichung

JSON-Eingabe ist auf 4 MiB und 64 Verschachtelungsebenen begrenzt und weist ungültiges UTF-8, doppelte Member, fehlerhafte numerische Limits und Int64-zu-Int32-Parameterkürzung zurück

Rohes UTF-8 und Unicode-Escapes tragen dieselben String-Werte, einschließlich ergänzender Zeichen als gültige UTF-16-Surrogatpaare; paarweise fehlende Surrogat-Escapes scheitern vor Dokumentmutation oder Binärveröffentlichung

Operationslimits umfassen memoryBytes, outputBytes, resultBytes und pixels; Dokumentlimits gelten auch für zuvor geladene Handles, während Limits für verwalteten Speicher und Rendering keine Prozess-RSS-Obergrenze versprechen

PDF- und PNG-Ausgabe ist vollständig vorbereitet und geprüft, bevor Output-Callbacks beginnen; ein Output-Callback im Aufruferbesitz kann nach seinem eigenen I/O-Fehler eine Teilübertragung behalten, aber fehlgeschlagene Binär- oder Ergebnisveröffentlichung committet keine Formularänderungen und ersetzt keinen zuvor geladenen Kontext

Erfolgreiche PDF-Mutationen committen die vorbereitete Ausgabe zugleich als aktuelles Dokument und als privaten Quell-Snapshot, sodass ein nachfolgender FDF- oder XFDF-Import mit gleichen Werten die exakten committeden PDF-Bytes mit updated=0 zurückliefert, unter Bewahrung früherer Formularfüllungen, getippter Rich-Appearances, gezeichneten Texts und importierter Seiten

Private Staging-Dateien werden entfernt, wenn der Kontext ersetzt oder zerstört wird; erfolgreiche inkrementelle Formular- und Signaturausgabe bewahrt das ursprüngliche Quellpräfix und die Verschlüsselungspolicy

Nachweise

Optionale Archivierungs-Schriftreparatur ermöglicht begrenzten Ghostscript-Ersatz und -Einbettung mit echter PDF/A-4-Validierung vor den Callbacks

Natives annotiertes Prüf-PDF ergänzt den semantischen Vergleich um echte vorbereitete PDF-Ausgabe, Unicode-Highlights und authentifizierte P3-Anmerkungsberechtigungen

Nativer Vertragsvergleich bietet begrenzten Zwei-Handle-Semantikvergleich, Unicode-Prüf-HTML und echte Quellzeilen-Geometrie

Allgemeiner nativer Dokumentvergleich normalisiert Objektgraphen und Stream-Kodierung, vergleicht echte Cairo-Pixel mit expliziten Schwellen und bewahrt Dokumentzustand und Callback-Veröffentlichungsbudgets

Der Abnahmeclient verifiziert echte C-Header-Layouts und versionierte Symbolauflösung, partielle Callbacks, 80 gleichzeitige Shared-Handle-Operationen, Abbruch, Unicode-Änderungen, Rollback und verschlüsseltes Signieren

Unabhängige pypdf-, MuPDF- und OpenSSL-Reader verifizieren die echten PDFs, PNG-Pixel, bewahrte Passwörter, Security-Dictionaries, Dokument-IDs, exakte ByteRange-Lücken, gültige Signaturen und die Zurückweisung veränderter signierter Bytes

Headless-Document-API · Natives Rendering · Verbleibender Lieferplan