ABI C Linux natif

HotPDFLinuxABI.lpr construit une bibliothèque partagée ELF x86_64 native nommée libhotpdf.so.1, avec SONAME libhotpdf.so.1 et symboles publics affectés à HOTPDF_1.0

La bibliothèque utilise THPDFHeadlessDocument et le rendu CPU sans composant Windows, sans bureau actif, sans lecteur PDF ni processus Python au runtime ; Python sert aux scripts de build et d’acceptation

Build et acceptation

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

Utilisez un FPC natif 3.2.2 ou plus récent avec FCL et paszlib, un compilateur C, binutils, Fontconfig et des polices TrueType installées ; l’environnement Python d’acceptation requiert aussi pypdf avec son provider AES, PyMuPDF, Pillow et NumPy

FPC_EXE, HPDF_LINUX_OUTPUT et PYTHON_EXE choisissent les emplacements d’outils ; l’environnement Python d’acceptation par défaut est /opt/hotpdf-python/bin/python

FPC écrit normalement un bloc d’exports anonyme dans sa réponse de linker ELF ; le build nomme ce bloc via la table de symboles versionnée du dépôt avant l’édition de liens, car ajouter un second script de versions nommé entrerait en conflit avec le bloc anonyme

Interface publique

Incluez Lib/hotpdf_abi.h pour la disposition des records partagés et les constantes de statut ; hpdf_abi_io_v1_size et hpdf_abi_operation_v1_size rapportent les tailles natives réelles des records

La bibliothèque Linux exporte la découverte ABI, la découverte de capacités, la création et destruction de documents, le chargement et la sauvegarde par callbacks, le comptage de pages, hpdf_document_execute_json_v1 et le point d’entrée hpdf_document_compare_json_v1 à deux documents

Découvrez les opérations courantes via hpdf_capabilities_json_to_io au lieu de supposer l’ensemble d’opérations Windows

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

Les workflows de signature natifs acceptent une identité PEM ou PFX Base64 explicite, des nouveaux champs de signature optionnels et des apparences Unicode, et des permissions de certification ; une signature réussie remplace le contexte chargé par la révision signée préparée, tandis qu’une signature ou publication échouée préserve le contexte original

Les options de signature natives lient une vraie sélection SHA256, SHA384 ou SHA512, des informations de signature Unicode, une attestation légale, des octets de confiance explicites, des preuves de révocation signées validées, de vrais préréglages d’apparences et une provenance d’identifiants ou de transport d’horodatage affirmée par l’application

L’état viewer optional-content optionnel fournit des applications explicites d’usage automatique View, Print ou Export, le zoom, la langue, le contexte utilisateur et des sélections manuelles locales à l’opération via des records V1 inchangés

L’opération render accepte usage: "view" ou usage: "print", avec view par défaut ; découvrez les choix via le tableau de capacités renderUsages, avec des records de callbacks et d’opérations V1 inchangés

Les drapeaux screen et printing des annotations suivent l’usage sélectionné, et annotations: false supprime les annotations dans les deux modes ; omettre optionalContent conserve la configuration par défaut statique, tandis qu’un objet explicite active les recommandations automatiques documentées et les sélections manuelles locales à l’opération

Tests/Linux/Run-LinuxABIRenderUsage.sh vérifie de vrais pixels PNG pour des sources plain et AES R5/R6, du contenu désactivé par défaut, des échecs de callbacks, des budgets, l’annulation et la récupération à handle identique ; voir Tests/Linux/HeadlessRenderUsage.en-us.md pour les dépendances de fixtures et le répertoire de fixtures pré-généré optionnel

Callbacks et durée de vie

Les options d’apparences de formulaires acceptent du texte Unicode, des valeurs d’export ou des tableaux de sélection complets, des états de boutons explicites, des réglages de polices et des limites de ressources transactionnelles

Les callbacks de lecture et d’écriture peuvent renvoyer des transferts partiels ; les transferts réussis doivent progresser positivement et ne pas dépasser le nombre demandé

Tous les callbacks s’exécutent de façon synchrone sur le thread appelant, y compris les vérifications d’annulation dans l’analyse de documents, le rendu et les checkpoints cryptographiques

L’entrée des callbacks est copiée dans un fichier temporaire privé créé exclusivement avec le mode 0600, si bien que les callbacks d’entrée Linux et leurs données utilisateur n’ont besoin de rester valides que jusqu’au retour de l’appel de chargement ou d’exécution

Les opérations sur un handle de document partagé se sérialisent en interne ; chaque appel actif détient une référence indépendante, si bien que détruire un handle depuis un callback de progression invalide les recherches suivantes tout en laissant l’appel courant se terminer sans risque

N’exécutez pas récursivement une autre opération sur le même handle depuis son callback ; gardez la bibliothèque partagée chargée jusqu’à ce que tous les appels soient revenus et chaque handle détruit

Budgets et publication

L’entrée JSON est limitée à 4 Mio et 64 niveaux d’imbrication, et rejette l’UTF-8 invalide, les membres dupliqués, les limites numériques mal formées et la troncature Int64-vers-Int32 des paramètres

L’UTF-8 brut et les échappements Unicode portent les mêmes valeurs de chaînes, y compris les caractères supplémentaires représentés par des paires de surrogates UTF-16 valides ; les échappements de surrogates non appariés échouent avant mutation du document ou publication binaire

Les limites d’opérations incluent memoryBytes, outputBytes, resultBytes et pixels ; les limites de documents s’appliquent aussi aux handles déjà chargés, tandis que la mémoire managée et les limites de rendu ne promettent pas de plafond de RSS process

La sortie PDF et PNG est entièrement préparée et vérifiée avant le début des callbacks de sortie ; un callback de sortie possédé par l’appelant peut retenir un transfert partiel après son propre échec d’E/S, mais une publication binaire ou de résultat échouée ne commite pas les éditions de formulaires ni ne remplace un contexte précédemment chargé

Les mutations PDF réussies committent la sortie préparée à la fois comme document courant et comme snapshot source privé, si bien qu’un import FDF ou XFDF ultérieur à valeur identique renvoie les octets PDF commités exacts avec updated=0, en conservant les remplissages de formulaires antérieurs, les apparences rich typées, le texte dessiné et les pages importées

Les fichiers de staging privés sont supprimés quand le contexte est remplacé ou détruit ; la sortie incrémentale réussie de formulaires et signatures préserve le préfixe source original et la politique de chiffrement

Preuves

La réparation de polices d’archivage optionnelle active une substitution et un embarquement Ghostscript bornés avec validation PDF/A-4 authentique avant les callbacks

Le PDF de revue annotée natif ajoute à la comparaison sémantique une vraie sortie PDF préparée, des surlignages Unicode et des permissions d’annotations P3 authentifiées

La comparaison native de contrats fournit une comparaison sémantique bornée à deux handles, un HTML de revue Unicode et une géométrie réelle de lignes sources

La comparaison native générale de documents normalise les graphes d’objets et l’encodage des flux, compare de vrais pixels Cairo avec des seuils explicites et préserve l’état des documents et les budgets de publication par callbacks

Le client d’acceptation vérifie les dispositions réelles des en-têtes C et la recherche de symboles versionnée, les callbacks partiels, 80 opérations concurrentes à handle partagé, l’annulation, les éditions Unicode, le rollback et la signature chiffrée

Des lecteurs indépendants pypdf, MuPDF et OpenSSL vérifient les PDF réels, les pixels PNG, les mots de passe conservés, les dictionnaires de sécurité, les IDs de documents, les intervalles ByteRange exacts, les signatures valides et le rejet d’octets signés modifiés

API documentaire headless · Rendu natif · Plan de livraison restant