Référence
Les pages de référence répondent à des questions ciblées : quel symbole, quelle valeur, quel niveau de prise en charge ou quelle clause. Cet onglet couvre le périmètre vérifié de NextPDF : référence des modules, matrices de prise en charge, surface d’API, référence des erreurs, conformité aux normes et politiques publiées par le projet. Rien ici n’explique comment atteindre un objectif ; pour cela, consulte les Guides ou le Cookbook.
Carte de référence
Section intitulée « Carte de référence »Moteur Core
Section intitulée « Moteur Core »Le moteur nextpdf/core, décrit module par module.
| Page | À quoi elle sert |
|---|---|
| Référence du moteur Core | La carte des espaces de noms : chaque page de module et les quatre sous-familles associées. |
| Contrats : 41 interfaces publiques (SPI) | Les interfaces publiques et les énumérations dont la stabilité fait l’objet d’un suivi. |
| Core : façade Document et traits de responsabilité | La façade Document et la famille de traits Has*. |
| HTML : sous-système de rendu HTML+CSS vers PDF | Le moteur de rendu HTML en flux, à passe unique. |
| Sécurité : chiffrement, politique cryptographique et surface de signature | Chiffrement, permissions et points d’intégration de la signature. |
Prise en charge du rendu
Section intitulée « Prise en charge du rendu »Ce que le moteur de rendu vérifie et déclare comme pris en charge, partiellement pris en charge ou non pris en charge.
| Page | À quoi elle sert |
|---|---|
| Matrice de prise en charge CSS | Les niveaux de prise en charge des feuilles de style en cascade (CSS), fonctionnalité par fonctionnalité, dans le pipeline HTML. |
| Fonctionnalités CSS non prises en charge et solutions de contournement | Ce qui est hors périmètre et les solutions de remplacement à utiliser. |
| Matrice de prise en charge des polices et des écritures | La prise en charge des technologies de polices et des systèmes d’écriture. |
| Prise en charge de l’écriture verticale CJK | La prise en charge du mode d’écriture vertical pour les textes chinois, japonais et coréens. |
| Prise en charge du façonnage des écritures complexes | La prise en charge du façonnage pour les systèmes d’écriture qui en ont besoin. |
Surface d’API
Section intitulée « Surface d’API »Symboles exacts, valeurs autorisées et contrats de service.
| Page | À quoi elle sert |
|---|---|
| Référence des énumérations | Chaque énumération publique et ses valeurs autorisées. |
| Configuration de la TSA | L’autorité d’horodatage (TSA) par défaut et la marche à suivre pour la changer. |
| Référence de l’API REST Connect | Les endpoints REST de NextPDF Connect, décrits dans le document OpenAPI 3.1. |
| Explorateur de l’API Connect | L’explorateur interactif du même contrat. |
Dans l’onglet Guides, les références d’API propres aux packages sont publiées avec les packages correspondants : Référence API de Connect, Index des API d’intégration et Référence de l’API Python.
Référence des erreurs
Section intitulée « Référence des erreurs »Toutes les exceptions susceptibles d’être levées par le moteur, classées par domaine, avec leur contexte structuré et des recommandations de reprise.
| Page | À quoi elle sert |
|---|---|
| Référence des erreurs | Le modèle d’exceptions : classe de base NextPdfException et contrat de contexte. |
| Erreurs du cœur et générales | Cycle de vie des documents et défaillances générales du moteur. |
| Erreurs de rendu et d’E/S | Défaillances du HTML, des polices, du writer et du reader. |
| Référence des erreurs : sécurité, signature et PKI | Défaillances du chiffrement, de la signature et de la PKI. |
| Erreurs d’exécution et de support | Défaillances HTTP, de résilience et d’observabilité. |
| Erreurs de l’Accelerator | Défaillances du sidecar facultatif d’accélération. |
| Référence des erreurs : erreurs de conformité | Défaillances de validation et de l’outillage de conformité. |
Conformité aux normes
Section intitulée « Conformité aux normes »Les profils de normes visés par NextPDF Core, avec, pour chacun, une limite explicite : le moteur produit une sortie destinée à être conforme ; la conformité est établie par un validateur externe.
| Page | À quoi elle sert |
|---|---|
| Conformité aux normes | La posture de conformité et l’index des profils. |
| Conformité PDF 2.0 | Le socle ISO 32000-2 que vise le moteur. |
| Conformité PDF/A-4 | Conformité d’archivage, avec la Correspondance des clauses PDF/A-4. |
| Conformité PDF/UA-2 | Conformité d’accessibilité, avec la Correspondance des clauses PDF/UA-2. |
| Conformité PDF/X | Conformité pour la production imprimée. |
| Correspondance des clauses PAdES | La correspondance avec le profil de base ETSI EN 319 142 pour les signatures PDF. |
| Conformité ZUGFeRD / Factur-X | Conformité pour les factures électroniques hybrides. |
Centre de confiance
Section intitulée « Centre de confiance »La posture d’ingénierie du moteur Core, avec les limites de chaque affirmation.
| Page | À quoi elle sert |
|---|---|
| Centre de confiance | L’index des postures publiées. |
| Licences produit | Les conditions de licence du cœur open source et des éditions commerciales. |
| Marque et usage de la marque | Les règles d’utilisation du nom et des marques NextPDF. |
| Gestion des données, des PII et de la télémétrie | Ce que le moteur lit, stocke et transmet. |
| Modèle de sécurité de la signature et du chiffrement | La conception cryptographique et ses limites. |
| Modèle de menaces du moteur | Les menaces contre lesquelles le moteur se défend et celles contre lesquelles il ne se défend pas. |
| Politique de divulgation des vulnérabilités | Comment signaler une vulnérabilité. |
Projet et versions
Section intitulée « Projet et versions »| Page | À quoi elle sert |
|---|---|
| Journal des modifications | Ce qui a changé dans chaque version. |
| Conventions de changelog | Comment les entrées du changelog sont rédigées et classées. |
| Politique de versionnage, de stabilité, de dépréciation et de support | Les garanties de compatibilité d’une version à l’autre. |
| Structure de la documentation NextPDF | La structure et la gouvernance de cet ensemble documentaire. |
Glossaire
Section intitulée « Glossaire »Glossaire : les termes employés dans cette documentation, définis une seule fois pour être réutilisés partout.
Contrat d’entrée de référence
Section intitulée « Contrat d’entrée de référence »Chaque entrée d’API doit répondre aux mêmes questions :
| Question | Réponse requise |
|---|---|
| Qu’appelles-tu ? | Symbole entièrement qualifié, endpoint, commande d’interface en ligne de commande (CLI) ou clé de configuration. |
| Quelles entrées sont acceptées ? | Tableau des paramètres indiquant le type, le caractère obligatoire, la valeur par défaut et les valeurs acceptées. |
| Que se passe-t-il par défaut ? | Comportement lorsque l’entrée facultative est omise. |
| Qu’est-ce qui est renvoyé ? | Type de retour, corps de réponse, fichier de sortie, flux ou effet de bord. |
| Qu’est-ce qui peut échouer ? | Exception, erreur de validation, statut HTTP ou mode de défaillance en exploitation. |
| Comment l’utiliser en toute sécurité ? | Notes sur la sécurité, la sûreté des workers, les limites de taille, les chemins, les délais d’attente et la gestion des secrets. |
Politique de couverture
Section intitulée « Politique de couverture »Les pages de référence consacrées aux API et aux comportements s’appuient sur le code source. Les API publiques sont documentées à partir du code source des packages, des fichiers de configuration, des tests et des exemples. Les classes utilitaires internes ne sont documentées que lorsqu’un développeur d’application doit comprendre leur comportement pour configurer ou exploiter le package.
État de préparation à la traduction
Section intitulée « État de préparation à la traduction »Les pages de référence privilégient les tableaux aux paragraphes denses. Chaque ligne doit être compréhensible isolément, car la segmentation ultérieure au format XLIFF (Extensible Localization Interchange File Format) découpera le contenu par bloc.