Journal des modifications

Historique des versions

Historique des versions de la bibliothèque PDFlibPas. Les entrées sont listées de la plus récente à la plus ancienne ; chaque version suit le versionnage sémantique conformément à la politique de publication du projet.

v3.56.42 2026-05-27

Le chemin de déchiffrement AES-256 basé sur un tampon introduit dans v3.56.41 a été corrigé afin que les appelants puissent réaffecter le résultat au même AnsiString que celui qui a fourni le tampon de texte chiffré sans violation d'accès.
Le flux de l'API normale LoadFromFile, Encrypt, SaveToFile, rechargement, Decrypt et SaveToFile se termine de nouveau sur les grands PDFs chargés tout en conservant l'optimisation de déchiffrement AES-CBC à copie réduite.
Une couverture de régression AES a été ajoutée pour les cas où le tampon d'entrée et le résultat partagent la même destination lors de la restauration des streams chiffrés pendant l'enregistrement, y compris de grands payloads de 504 Ko qui révélaient auparavant l'échec.

v3.56.41 2026-05-27

Ajout de TPDFlib.DACopyFile pour les workflows Direct Access qui nécessitent un nombre de pages et une copie de fichier inchangée sans construire le graphe complet des objets normaux.
Optimisation du déchiffrement AES-256 avec des chemins AES-CBC basés sur tampon, utilisés lors du déchiffrement des chaînes et streams chargés, afin de réduire les copies supplémentaires de texte chiffré sur les grands streams chiffrés.
La demo Delphi HugeFileBenchmark inclut maintenant une ligne direct-copy ainsi que les filtres --ops et --skip pour des exécutions ciblées sur les gros fichiers.

v3.56.40 2026-05-26

Les demos Delphi et C++Builder HelloWorld creent maintenant un PDF de depart plus riche avec informations de document, sortie dans une police standard selectionnee, bloc de titre stylise, dessin vectoriel simple et indications de suite, tout en conservant le meme flux compiler-et-executer.
Toutes les notes des demos Delphi et C++Builder ont ete remplacees par des pages Readme.html lisibles dans un navigateur, y compris les notes auxiliaires sur les mots de passe, les fichiers restreints et les resultats de signature; les index de demos dirigent maintenant les utilisateurs vers les notes HTML.

v3.56.39 2026-05-26

Les chemins de sauvegarde de l'API de fichiers directs construisent désormais les tables de recherche des références croisées de façon linéaire, ce qui rend DASaveAsFile et les chemins de sauvegarde directe associés beaucoup plus rapides sur les PDF contenant de très nombreux objets ou des arbres de pages denses.
Le writer optimisé conserve la même sémantique de chaîne des objets libres tout en évitant les balayages répétés des numéros d'objets pendant la génération complète de xref, ce qui améliore les grands flux de sauvegarde directe sans modifier l'API publique ni le contrat de sortie.

v3.56.38 2026-05-26

La sortie de chiffrement de l'API normale a été corrigée afin que Encrypt crée ou conserve le trailer /ID avant d'écrire les données de sécurité AES-256, ce qui permet aux PDFs chiffrés de rester détectables au rechargement via EncryptionStatus.
Le workflow de l'API normale LoadFromFile, Encrypt, SaveToFile, rechargement, Decrypt et SaveToFile conserve maintenant l'état chiffré avant le Decrypt explicite, avec le même comportement que l'API d'accès direct aux fichiers pour les grands PDFs hérités.

v3.56.37 2026-05-26

Ajout de TPDFlib.ComparePreflightReports, un comparateur ligne par ligne pour les rapports de preflight en texte brut qui ignore les lignes d'horodatage volatiles Generated: et renvoie une chaine vide lorsque le contenu stable du rapport correspond.
La demo Delphi PreflightReport prend desormais en charge --compare <file> en mode fichier unique, ecrit un rapport UTF-8 .diff.txt et renvoie le code de sortie 2 lorsque le rapport texte genere differe de la baseline.

v3.56.36 2026-05-26

La demo Delphi PreflightReport prend maintenant en charge les traitements de repertoire par lot avec --input-dir, --output-dir et --recursive, en ecrivant un rapport par PDF sous la forme <basename>.preflight.<ext>.
Le mode lot ecrit un fichier UTF-8 preflight-summary.csv qui enregistre chaque PDF source, le statut pass/fail, le nombre de problemes et le chemin du rapport genere, tout en conservant le contrat de codes de sortie existant pour l'automatisation.

v3.56.35 2026-05-26

ReportFormat = 3 ajoute la sortie CSV a TPDFlib.CreatePreflightReportEx et TPDFlib.SavePreflightReportEx, avec des lignes UTF-8 pour les metadonnees du rapport, chaque controle de conformite selectionne, les codes et messages de probleme individuels, et le resume final.
La demo Delphi PreflightReport prend maintenant en charge --format csv et --csv, afin que les controles preflight en ligne de commande alimentent des feuilles de calcul ou de simples analyseurs CI sans post-traiter JSON ni extraire du texte.

v3.56.34 2026-05-26

Ajout des API sensibles au format TPDFlib.CreatePreflightReportEx et TPDFlib.SavePreflightReportEx pour produire des rapports preflight PDF/A et PDF/UA-1 en texte brut, JSON ou HTML autonome, tout en conservant les API existantes limitées au texte.
La démo Delphi PreflightReport prend maintenant en charge --format text|json|html ainsi que les raccourcis --json et --html, afin que le même flux en ligne de commande produise des rapports lisibles ou des artefacts CI exploitables par machine.

v3.56.33 2026-05-26

Ajout de TPDFlib.CreatePreflightReport et TPDFlib.SavePreflightReport, afin que les applications puissent produire des rapports texte réutilisables à partir des contrôles de conformité PDF/A et PDF/UA-1 intégrés sans parcourir manuellement les handles de listes de chaînes.
La démo Delphi PreflightReport appelle maintenant directement les API de rapport de la bibliothèque, ce qui garde l'exemple centré sur le flux en ligne de commande, les contrôles choisis, le mode premier problème et les codes de sortie adaptés à l'automatisation.

v3.56.32 2026-05-26

Ajout d'un nouvel exemple console Delphi PreflightReport qui exécute les contrôles PDF/A et PDF/UA-1 avec CheckFileCompliance, énumère les listes de problèmes avec GetStringListCount et GetStringListItem, puis écrit un rapport de preflight en texte brut.
L'exemple prend en charge les options --input, --output, --pdfa, --pdfua, --both et --first-issue, ainsi que des codes de sortie adaptés à l'automatisation pour réussite, problèmes détectés et erreur d'exécution.

v3.56.31 2026-05-25

GetCustomKeys(2) masque désormais de manière cohérente les entrées du système Catalog gérées par la bibliothèque, notamment /OutputIntents, /Extensions, /Requirements, /Collection et /NeedsRendering.
Les profils de sortie PDF/A créés par SetPDFAMode ne sont plus affichés comme des clés personnalisées dans le catalogue, ce qui permet de séparer l'énumération des métadonnées de l'application des structures de conformité PDF.

v3.56.25 2026-05-23

Le module GetPDFUADiagnostics côté rédacteur corrige le problème MULTIPLE-H-CHILDREN:N correspondant, assurant la parité avec le module 10044 à partir de v3.56.24. ISO 14289-1 §7.4.4 interdit qu'un nœud d'arbre de balises ait plus d'un enfant H direct ; la vérification côté rédacteur s'exécute chaque fois que l'arbre FStructElems en mémoire contient une telle violation.
Un nouveau module CountMultipleHChildren auxiliaire parcourt l'arbre en profondeur, en comptant les enfants H à chaque niveau. La vérification s'exécute en parallèle avec les parcours existants LIST-STRUCT / LIST-NO-NUMBERING et utilise le même motif de parcours FStructElems.

v3.56.24 2026-05-23

Le module d'audit PDF/UA-1 gagne une vérification de l'unicité des balises H ISO 14289-1 §7.4.4. 10044 signale tout nœud de structure qui contient plus d'un enfant H direct —, car la spécification interdit cela dans les documents fortement structurés, et la même contrainte s'applique à tout nœud d'arbre de balises, quel que soit le mode de structure global. L'autre exigence § 7.4.4 (un document doit être soit fortement structuré, soit faiblement structuré, mais pas les deux) nécessite des heuristiques à l'échelle du document et est intentionnellement exclue de cet audit.
Un nouveau parcoursur d'arbre de structure en préordre (UAVisitStructNodeForHUniqueness / ScanStructTreeForHUniqueness) compte les enfants H directs par nœud et effectue une récursion en profondeur. Réutilise le même décodeur en forme de K que les parcoursurs de titres/listes/notes existants.

v3.56.23 2026-05-23

L'audit PDF/UA-1 prend en charge les deux vérifications de programme de police ISO 14289-1 §7.21.6 qui permettaient aux vérifications de la couche de dictionnaire de v3.56.10 de différer jusqu'à ce qu'un analyseur TrueType soit disponible. 10034 signale les programmes TrueType non symboliques dont la table cmap intégrée contient uniquement l'entrée symbolique (platformID=3, encodingID=0) — §. Le premier paragraphe de la version 7.21.6 exige au moins une sous-table cmap non symbolique afin que le programme puisse rendre les points de code déclarés par son /Encoding.. 10035 signale les tableaux TrueType non symboliques dont les noms de glyphes ne sont pas des membres de la liste Adobe Glyph (sauf .notdef). — §. Le troisième paragraphe de la version 7.21.6 exige que chaque entrée de différence soit présente dans AGL.
La nouvelle version Lib/PDFlibPDFUAFontInspect.pas implémente un analyseur de répertoire de table tolérant et un analyseur de répertoire de sous-table cmap. La table Adobe Glyph List de 4281 noms, ajoutée comme structure de base dans la validation précédente, est maintenant intégrée via la vérification des différences. Les programmes qui ne sont pas analysés comme des polices SFNT (police PFB / PFA, collection, données aléatoires) sont ignorés silencieusement. Les faux négatifs sont préférés aux faux positifs au niveau de l'audit.

v3.56.22 2026-05-23

L'audit PDF/UA-1 prend en charge les vérifications des données de clip multimédia. 10042 signale les dictionnaires de données de clip multimédia (identifiés par /S /MCD, éventuellement /Type /MediaClip) qui ne contiennent pas l'entrée de type de contenu /CT requise. 10043 signale les mêmes dictionnaires qui ne contiennent pas le tableau /Alt requis. ISO 32000-1 Le tableau 274 indique que les deux clés sont facultatives, mais ISO 14289-1 §7.18.6 les rend obligatoires afin que les lecteurs d'écran puissent annoncer une description significative pour les supports multimédias intégrés.
Ceci est la phase 6 du plan d'audit approfondi PDF/UA (.superpowers/plans/2026-05-23-pdfua-deep-audit-plan.md). Il s'exécute sans aucune dépendance de l'analyseur de programme de police ou du flux de contenu, il s'agit donc du premier sous-classe après la série v3.56.0..v3.56.13.

v3.56.21 2026-05-23

La nouvelle fonctionnalité SetSignProcessCommitmentType émet l'attribut signé CAdES commitment-type-indication (OID 1.2.840.113549.1.9.16.2.16, ETSI EN 319 122-1 v1.2.1 §5.2.3) à l'intérieur du chemin PAdES-B-B SignerInfo. Elle accepte des codes entiers de 1 à 6, qui correspondent aux engagements ETSI bien connus id-cti-ets-proofOfOrigin à id-cti-ets-proofOfCreation ; utilisez 0 pour effacer. Les codes hors plage sont rejetés.
La nouvelle fonctionnalité SetSignProcessSignaturePolicy émet l'attribut signé CAdES signature-policy-identifier (OID 1.2.840.113549.1.9.16.2.15, §5.2.9). Elle prend en charge la politique au format décimal pointé OID, le hachage du document de politique sous forme de chaîne hexadécimale en majuscules et un code d'algorithme de hachage (1=SHA-1, 2=SHA-256, 3=SHA-384, 4=SHA-512, 0=auto/SHA-256). L'attribut contient la SignaturePolicyId SEQUENCE avec sigPolicyId + sigPolicyHash (OtherHashAlgAndValue SEQUENCE).
Ces deux attributs ne prennent effet que lorsque la SubFilter est ETSI.CAdES.detached (le chemin PAdES-B-B) ; ils étendent le tableau rgAuthAttr existant, en plus de content-type et signing-certificate-v2. Le tableau 1, ligne d), interdit de combiner commitment-type-indication avec l'entrée du dictionnaire de signature PDF /Reason ; l'appelant est responsable de ne pas définir les deux.

v3.56.20 2026-05-23

La nouvelle fonctionnalité AddPAdESDSSVRI ajoute une entrée de sous-dictionnaire Signature VRI à l'objet DSS en cours de construction, complétant la structure ETSI EN 319 142-1 v1.2.1 clause 5.4.2.3 Informations de validation. L'entrée est indexée par la valeur hexadécimale en majuscules SHA-1 des octets de la signature ' ; ses sous-tableaux Cert / CRL / OCSP sont remplis en faisant référence aux flux parents correspondants via des index basés sur zéro fournis sous forme de listes séparées par des virgules (par exemple, "0,2,5").
La fonctionnalité sous-jacente TSmartPDFDocument.AddPAdESDSSWithVRI suit les numéros d'objet de flux émis pour chaque certificat / CRL / OCSP et les utilise pour écrire les sous-tableaux VRI en tant que références indirectes vers les mêmes flux auxquels les tableaux parents DSS pointent déjà, ce qui satisfait l'exigence de la spécification selon laquelle les entrées VRI partagent le stockage avec le dictionnaire parent DSS. Le point d'entrée AddPAdESDSS original continue de fonctionner sans modification pour les appelants qui n'ont pas besoin de la fonctionnalité VRI.
Chaque sous-dictionnaire VRI par signature contient le marqueur optionnel /Type /VRI, de sorte que les outils qui parcourent le catalogue par balises Type peuvent reconnaître la structure sans avoir à résoudre le chemin parent.

v3.56.19 2026-05-23

Nouveau flux de travail PAdES-B-T pour joindre une signature-horodatage (id-aa-signatureTimeStampToken, OID 1.2.840.113549.1.9.16.2.14) à une signature PAdES-B-B existante. NewPAdESSignatureTimeStampProcessFromFile / FromStream / FromString ouvre un PDF signé, SetPAdESSignatureTimeStampField nomme le champ, GetPAdESSignatureValueHashHex renvoie le hachage SHA-256 (ou 384 / 512) du signatureValue du signataire pour la soumission à une TSA, GetPAdESSignatureCMSBytes expose la charge utile CMS existante, SetPAdESSignatureCMSBytes accepte les octets augmentés CMS que l'appelant assemble via sa bibliothèque CMS de choix, et EndPAdESSignatureTimeStampProcessToFile / ToStream / ToString insère la nouvelle CMS dans le placeholder /Contents original.
BuildPAdESSignatureTimeStampAttribute est un utilitaire sans état qui encapsule un TimeStampToken émis par TSA dans l'attribut CMS que SignerInfo.unsignedAttrs attend, de sorte que les appelants qui disposent déjà d'une bibliothèque CMS peuvent éviter la complexité de OID + SET.
La nouvelle SetSignProcessReserveContentsBytes élargit le placeholder /Contents au moment de la signature initiale afin que le CMS augmenté ultérieurement tienne sans déborder de la réservation initiale. Les attributs TimeStampTokens typiques émis par 13 ajoutent 2 à 6 KB au SignerInfo ; indiquez 1024-8192 pour laisser de la marge. En cas de réserve insuffisante, l'appel d'augmentation renvoie 13 (dépassement de la sortie).
La bibliothèque ne fournit pas de client TSA HTTP ; l'appelant récupère l'attribut TimeStampToken (généralement 30 à 50 lignes de requête TSP + HTTP POST par rapport à, par exemple, FreeTSA ou DigiCert). Sur Windows, CMSG_CTRL_ADD_SIGNER_UNAUTH_ATTR pourrait, en principe, automatiser l'injection CMS dans la bibliothèque, mais renvoie CRYPT_E_INVALID_INDEX (0x80091008) pour la forme détachée SignedData PAdES émise, de sorte que les octets CMS fournis par l'appelant sont utilisés à la place.

v3.56.18 2026-05-23

L'attribut PAdES signing-certificate-v2 inclut désormais le champ optionnel IssuerSerial défini par RFC 5035 (ESSCertIDv2). Le nom distinctif de l'émetteur du certificat de signature est encapsulé dans un GeneralName [4] EXPLICIT directoryName CHOICE dans GeneralNames, suivi du numéro de série du certificat en tant que ASN.1 INTEGER. Les octets du numéro de série arrivent en ordre little-endian depuis Windows CryptoAPI (CRYPT_INTEGER_BLOB) et sont inversés en ordre big-endian avec l'ajout de l'octet de remplissage entier positif lorsque le bit de poids fort est activé, comme OpenSSL et BouncyCastle émettent le même champ.
Les vérificateurs qui vérifient le nom de l'émetteur + la paire numéro de série par rapport à leur ensemble de candidats de construction de chemin (notamment EU DSS en mode strict) trouvent maintenant les deux identificateurs dans l'attribut signing-cert-v2 ; la sortie v3.56.17 précédente ne fournissait que la référence certHash.
Les nouveaux utilitaires ASN.1 DER_IntegerFromLittleEndian (gère l'ordre d'octet Win32 CRYPT_INTEGER_BLOB) et DER_ContextTagExplicit (encapsule une charge utile dans une étiquette contextuelle construite) complètent le micro-encodeur PDFlibASN1. Les nouvelles déclarations CERT_INFO / CRYPT_ALGORITHM_IDENTIFIER / CRYPT_INTEGER_BLOB / PCERT_CONTEXT dans PDFlibCryptoAPI donnent au chemin de signature accès aux champs de certificat analysés.

v3.56.17 2026-05-23

Le chemin de signature intégré ETSI.CAdES.detached produit désormais des signatures PAdES-B-B structurellement conformes. La bibliothèque construit elle-même les attributs authentifiés CMS — content-type (id-data) et signing-certificate-v2 issus de RFC 5035 / RFC 5816, accompagnés d'un hash SHA-256 du certificat de signature — et les transmet à CryptSignMessage via rgAuthAttr. Dès que ce champ n'est plus NULL, l'API Windows CryptoAPI cesse d'injecter automatiquement l'attribut signing-time que PAdES (ETSI EN 319 142-1 v1.2.1 Table 1) interdit, de sorte que le SignerInfo résultant ne porte que les attributs requis et eux seuls.
La nouvelle unité PDFlibASN1 fournit un micro-encodeur DER (X.690) ciblé — préfixe de longueur, OCTET STRING, SEQUENCE, SET, OBJECT IDENTIFIER — utilisé pour bâtir la valeur de l'attribut SigningCertificateV2. L'encodeur respecte les règles standard des arcs OID en base-128 et omet le champ optionnel hashAlgorithm lorsque celui-ci ne ferait que répéter la valeur par défaut SHA-256, comme le font OpenSSL et BouncyCastle.
ApplySignature achemine désormais ETSI.CAdES.detached par le chemin raw-byte (le même que celui utilisé par adbe.pkcs7.detached) au lieu de fournir un digest précalculé. La CryptoAPI calcule maintenant l'attribut authentifié messageDigest sur le contenu effectivement signé, ce qui correspond à ce qu'attendent les vérificateurs.
SHA-384 et SHA-512 sont également honorés lors de la construction de l'attribut signing-certificate-v2 : le champ hashAlgorithm est émis avec l'AlgorithmIdentifier correspondant plutôt que de s'appuyer sur la valeur par défaut. SHA-1 est silencieusement promu en SHA-256 dans ce contexte, car PAdES-B-B n'autorise pas SHA-1 (clause 6.2.1).

v3.56.16 2026-05-23

Le nouveau SetSignProcessDigestAlgorithm sélectionne l'algorithme de message-digest pour la signature : 1 = SHA-1 (deprecated), 2 = SHA-256 (valeur par défaut moderne), 3 = SHA-384, 4 = SHA-512, 0 = auto (SHA-256 pour chaque SubFilter sauf le chemin légat adbe.pkcs7.sha1, qui reste sur SHA-1 pour conserver une compatibilité binaire stable). ETSI EN 319 142-1 v1.2.1 §6.2.1 interdit MD5 et renvoie à ETSI TS 119 312 pour les suites cryptographiques recommandées, donc les signataires PAdES doivent choisir SHA-256 ou plus fort.
Ajout des helpers de hachage SHA256StreamRange, SHA384StreamRange et SHA512StreamRange à côté du SHA1StreamRange existant ; le chemin de signature les utilise pour hacher le ByteRange du PDF avec l'algorithme sélectionné. L'OID SignerInfo.digestAlgorithm de PKCS#7 et les octets de hachage effectivement écrits sont désormais garantis cohérents (le code précédent transmettait toujours le digest SHA-1 quel que soit l'algorithme négocié).
TPDFlibPFXFile.SignData prend désormais un paramètre DigestAlgorithm et choisit l'OID correct pour chaque paire (SubFilter, algorithme) : 2.16.840.1.101.3.4.2.1 / .2 / .3 pour SHA-256/384/512 sur les SubFilters detached et custom (RFC 5754), et les OIDs de la famille sha256WithRSAEncryption correspondants pour le chemin légat adbe.pkcs7.sha1.

v3.56.15 2026-05-23

Nouveau SetSignProcessDocTimeStamp bascule un processus de signature en mode PAdES Document Time-stamp conformément à ETSI EN 319 142-1 v1.2.1 §5.4.3. Le dictionnaire de signature résultant porte /Type /DocTimeStamp et /SubFilter /ETSI.RFC3161, omet les clés interdites /M, /Reason, /Location, /ContactInfo et /Name, et réserve un espace réservé hexadécimal de 8192 octets (ou de la taille spécifiée par l'appelant) dans /Contents pour un TimeStampToken RFC 3161 récupéré en externe.
Le mode passthrough est activé automatiquement lorsque le mode DocTimeStamp est sélectionné car le TimeStampToken provient d'une TSA externe. Les appels à SetSignProcessInfo effectués après le basculement en mode DocTimeStamp sont silencieusement ignorés pour maintenir le dictionnaire de signature conforme à la spécification.
L'auto-injection PAdES /Extensions /ESIC existante ajoutée en v3.56.8 couvre déjà DocTimeStamp car son SubFilter commence par ETSI., de sorte qu'un PDF Document Time-stamp déclare l'extension de catalogue requise sans câblage supplémentaire.

v3.56.14 2026-05-23

Nouvelle API d'augmentation PAdES Document Security Store (DSS). NewPAdESDSSProcessFromFile / NewPAdESDSSProcessFromStream / NewPAdESDSSProcessFromString ouvrent un PDF précédemment signé, AddPAdESDSSCertificate / AddPAdESDSSCRL / AddPAdESDSSOCSP mettent en file le matériel de validation encodé en DER, et EndPAdESDSSProcessToFile / EndPAdESDSSProcessToStream / EndPAdESDSSProcessToString écrivent une mise à jour incrémentale contenant un dictionnaire /DSS << /Type /DSS /Certs [...] /CRLs [...] /OCSPs [...] >> tel que spécifié par ETSI EN 319 142-1 v1.2.1 §5.4.2.2. C'est la brique de base pour promouvoir une signature PAdES-B-B / B-T en validation à long terme PAdES-B-LT.
Le processus DSS élève automatiquement l'entrée de catalogue /Extensions /ESIC à au moins ExtensionLevel 1 lors de l'ajout de matériel de validation, conformément à l'exigence du §5.6, et fusionne les nouveaux certificats, CRL et réponses OCSP dans les tableaux existants /Certs / /CRLs / /OCSPs lors d'invocations répétées afin que les révisions s'accumulent au lieu de s'écraser.
GetPAdESDSSProcessResult / ReleasePAdESDSSProcess complètent le cycle de vie, reproduisant la surface d'API SignProcess existante.

v3.56.8 2026-05-23

Conformité PAdES baseline : lorsqu'une signature est créée avec un SubFilter PAdES (ETSI.CAdES.detached ou ETSI.RFC3161), le catalogue du document reçoit désormais automatiquement l'entrée /Extensions /ESIC <</BaseVersion /1.7 /ExtensionLevel 2>> requise par ETSI EN 319 142-1 v1.2.1 §5.6. L'entrée est ajoutée via la même mise à jour incrémentale qui porte la signature, ne dégrade jamais un /ExtensionLevel existant plus élevé, et suit les références indirectes /Extensions ou /ESIC lorsque le PDF source les stocke déjà comme objets séparés.
Le marqueur d'extension équivalent Adobe écrit par SetSignProcessCustomSubFilter pour les PDF créés via TPDFlib est désormais /ADBE /BaseVersion /1.7 /ExtensionLevel 8 (était ExtensionLevel 5), correspondant à la déclaration alternative que les signatures PAdES baseline sont autorisées à utiliser ; le niveau 5 ne couvrait que les fonctionnalités formulaires / 3D / RichMedia ISO 32000-2 et n'identifiait pas réellement les extensions PAdES.

v3.56.13 2026-05-23

Lorsque SetPDFUAMode est actif et que le document est enregistré, tout élément de structure L (liste) auquel manque un attribut ListNumbering explicite reçoit désormais automatiquement /O = List /ListNumbering = None. ISO 14289-1 §7.6 requiert que chaque balise L déclare son style de numérotation ; la nouvelle correction au moment de l'enregistrement ApplyPDFUAListNumbering rejoint la famille existante ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship / ApplyPDFUAStripTrapNet.
Les auteurs qui se soucient d'un style de liste spécifique doivent toujours appeler SetStructElemListNumbering avant EndTag ; l'auto-correction ne se déclenche que lorsqu'aucun attribut ListNumbering n'est présent au moment de l'enregistrement, donc les valeurs explicites sont préservées.
Le message de diagnostic côté writer LIST-NO-NUMBERING:N note désormais que l'auto-correction masquera le problème au moment de l'enregistrement, afin que les utilisateurs comprennent à la fois l'attribut manquant et le comportement de réparation automatique.

v3.56.12 2026-05-23

L'audit PDF/UA-1 gagne trois nouvelles vérifications ISO 14289-1. 10031 signale les annotations Link dont le dictionnaire d'action URI porte /IsMap = true (interdit par §7.18.5 sauf si une fonctionnalité équivalente est fournie ailleurs dans le contenu ; les auteurs avec un cas d'utilisation IsMap légitime peuvent supprimer le diagnostic par eux-mêmes). 10032 signale les éléments de structure Note auxquels manque l'entrée /ID — §7.9 requiert que chaque balise Note déclare un ID unique. 10033 signale les comptes de paires en double lorsque deux balises Note ou plus partagent la même valeur /ID.
La détection de collision d'ID de Note est effectuée en collectant les ID dans une TStringList triée et en parcourant les paires adjacentes, donc un groupe de trois Notes partageant un seul ID compte comme deux paires en double.
La vérification d'action URI parcourt le tableau /Annots de chaque page, filtre par /Subtype /Link, puis inspecte /A /S /URI et le booléen /IsMap. Les références indirectes sont déréférencées à chaque étape afin que les dictionnaires d'action séparés se comportent de la même manière que ceux en ligne.

v3.56.11 2026-05-23

ISO 14289-1 §7.6 requiert que chaque élément de structure L (liste) porte un attribut ListNumbering explicite. 10030 (côté reader) et LIST-NO-NUMBERING:N (côté writer) signalent les balises L qui l'omettent. Le parcoureur côté reader décode les deux formes /A (dictionnaire d'attribut unique, ou un tableau de dictionnaires mélangés avec des entiers de révision) et recherche la clé /ListNumbering quel que soit le propriétaire. La vérification côté writer inspecte TPDFStructElem.Attributes pour le même nom à la fois dans la liste de structure finalisée et dans la pile de balises encore ouvertes.
Les valeurs ListNumbering valides selon ISO 32000-1 Table 347 sont None, Disc, Circle, Square, Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha. L'audit vérifie uniquement la présence de la clé, pas quelle valeur est choisie — chaque balise L a besoin de l'une d'elles.

v3.56.10 2026-05-23

L'audit PDF/UA-1 gagne les règles d'encodage TrueType ISO 14289-1 §7.21.6. 10028 signale les polices TrueType non symboliques dont /Encoding (ou le /BaseEncoding à l'intérieur d'un dictionnaire Encoding) n'est ni MacRomanEncoding ni WinAnsiEncoding. 10029 signale les polices TrueType symboliques qui portent une entrée /Encoding tout court (interdit par §7.21.6 quatrième paragraphe).
Symbolique vs non symbolique est décidé à partir du bit 3 de /Flags du FontDescriptor (masque 4), réutilisant l'assistant UAFontDescriptorSymbolic existant de la sous-classe 4. Le premier paragraphe complet du §7.21.6 (le programme TrueType intégré doit contenir des entrées cmap correspondantes) requiert l'analyse du programme de police TrueType et est toujours en attente ; les règles au niveau du dictionnaire ci-dessus sont la couche pratique que cet audit peut vérifier sans analyseur TrueType.
Les règles de tableau Differences dans §7.21.6 (noms de glyphe AGL uniquement, présence de cmap Microsoft Unicode) restent hors de portée pour la même raison — elles requièrent l'inspection du programme de police.

v3.56.9 2026-05-23

L'audit PDF/UA-1 gagne une vérification ISO 14289-1 §7.18.4 complète. 10027 signale les annotations Widget dont /StructParent se résout via le /ParentTree de l'arbre de structure mais ne se termine pas sur un élément de structure avec /S = Form. La précédente vérification partielle v3.56.7 (10026) ne détectait que les Widgets auxquels manquait entièrement /StructParent ; la nouvelle vérification complète la règle en suivant le pointeur d'arbre numérique et en vérifiant la balise de destination.
Un nouvel assistant NumberTreeLookup implémente la forme d'arbre numérique ISO 32000-1 §7.9.7 (racine plate /Nums, /Kids intermédiaires délimités par /Limits). Les futurs audits qui ont besoin de résoudre les entrées de page /StructParents ou les étiquettes /PageLabels peuvent le réutiliser.
La vérification de balise Form pour annotation Widget utilise un modèle à deux niveaux : un Widget sans /StructParent est signalé comme 10026 ; un Widget dont /StructParent existe mais ne se résout pas en /S = Form est signalé comme le plus spécifique 10027. Cela évite de compter deux fois la même violation sous les deux codes.

v3.56.7 2026-05-23

Lorsque SetPDFUAMode est actif et que le document est enregistré, toute entrée d'annotation TrapNet est désormais automatiquement supprimée du tableau /Annots de chaque page. ISO 14289-1 §7.18.2 interdit les annotations TrapNet ; la nouvelle correction au moment de l'enregistrement ApplyPDFUAStripTrapNet rejoint la famille existante ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship afin que les documents en mode PDF/UA cessent d'émettre silencieusement des résidus TrapNet.
L'audit PDF/UA-1 gagne une vérification partielle §7.18.4. 10026 signale les annotations Widget auxquelles manque /StructParent — un Widget sans /StructParent ne peut pas être atteint depuis l'arbre de structure et ne peut donc pas être imbriqué dans une balise de structure Form. La vérification structurelle complète (résolution de /StructParent via le ParentTree et confirmation que le /S parent est Form) est laissée à une version de suivi.
GetPDFUADiagnostics côté writer gagne l'incident correspondant WIDGET-NO-STRUCTPARENT:N. Le message TRAPNET-ANNOT existant note également désormais que SetPDFUAMode les supprime automatiquement au moment de l'enregistrement.

v3.56.6 2026-05-23

L'audit PDF/UA-1 gagne deux vérifications de hiérarchie de titres ISO 14289-1 §7.4.2. 10024 signale lorsque le premier élément de titre dans l'ordre du document n'est pas H1 (ou H). 10025 signale le nombre de sauts de niveau de titre dans une séquence descendante (par ex. H1 suivi de H3 sans H2). Les deux vérifications partagent un seul parcours en préordre de l'arbre de structure qui décode les formes /K imbriquées (StructElem unique, tableau de StructElems / IndRefs / MCRs).
GetPDFUADiagnostics côté writer gagne l'incident correspondant FIRST-HEADING-NOT-H1, parité avec le reader 10024. La vérification writer HEADING-LEVEL-SKIP précédemment existante a désormais une compagne qui attrape également les problèmes de style « le premier titre était H2 ».

v3.56.5 2026-05-23

Lorsque SetPDFUAMode est actif et que le document est ultérieurement chiffré, la clé d'autorisation de chiffrement (/P dans le dictionnaire de chiffrement) a désormais automatiquement le bit 10 (masque $200, « Extraire le texte et les graphiques en support à l'accessibilité ») défini, même lorsque l'appelant n'a pas inclus ppCanCopyAccess dans les TPDFExtraPermissions passées à Encrypt. ISO 14289-1 §7.16 requiert que chaque fichier chiffré conforme permette l'extraction pour accessibilité, et le bit est par ailleurs facile à oublier. Le bit est toujours sûr à définir — il n'accorde qu'un accès supplémentaire aux technologies d'assistance, pas aux autres chemins d'extraction.
GetPDFUADiagnostics côté writer gagne un nouvel incident ENCRYPT-NO-ACCESS qui se déclenche lorsque PDFUAMode est actif et que le bit 10 de /P du dictionnaire de chiffrement est effacé. Cela attrape le cas limite d'ordre d'appel dans lequel l'utilisateur a appelé Encrypt() en premier et SetPDFUAMode seulement après — le diagnostic indique à l'utilisateur d'appeler à nouveau Encrypt() afin que le dictionnaire de chiffrement soit ré-émis avec le /P corrigé.

v3.56.4 2026-05-23

GetPDFUADiagnostics côté writer gagne cinq nouvelles vérifications ISO 14289-1 afin que l'audit de document en mémoire attrape les mêmes violations que l'audit ComplianceTest=2 de CheckFileCompliance côté reader. SUSPECTS-TRUE signale MarkInfo/Suspects=true (§7.1 : les fichiers conformes PDF/UA requièrent Suspects=false). ROLEMAP-STANDARD-REMAP:N signale les appels AddRoleMap qui remapperaient une balise de structure standard — §7.1 interdit de remapper les balises standard. DC-TITLE-MISSING signale un XMP dc:title vide (distinct de DOCINFO-TITLE-MISSING, qui vérifie /Info /Title). TRAPNET-ANNOT:N signale les annotations TrapNet (§7.18.2 les interdit). ANNOT-PAGE-NO-TABS-S:N signale les pages portant des annotations dont le dictionnaire de page /Tabs n'est pas /S (§7.18.3 requiert un ordre de tabulation par arbre de structure sur ces pages).
Les audits PDF/UA-1 côté writer et côté reader sont désormais à peu près à parité : chaque incident que l'audit côté reader signale sur un fichier enregistré est également atteignable depuis le diagnostic en mémoire, modulo les conventions de format de chaque fonction (texte séparé par sauts de ligne vs liste de chaînes de code NNNNN).

v3.56.3 2026-05-23

L'audit PDF/UA-1 gagne ses vérifications de polices §7.21. 10020 signale toute police non Standard-14 dont le FontDescriptor manque FontFile/FontFile2/FontFile3 (§7.21.4.1 : chaque police rendue doit intégrer son programme). 10021 signale les descendants CIDFontType2 sans entrée /CIDToGIDMap (§7.21.3.2). 10022 signale les polices Standard 14 (Helvetica, Times, Courier, Symbol, ZapfDingbats et variantes gras / oblique) référencées sans programme intégré — §7.21.4 NOTE 5 indique clairement qu'il n'y a pas d'exemption d'intégration pour ces polices. 10023 signale les polices auxquelles manque une CMap /ToUnicode et qui ne correspondent pas à la liste d'exemption du §7.21.7 (encodages prédéfinis MacRoman / MacExpert / WinAnsi, Type 0 avec collections de caractères Adobe-GB1 / CNS1 / Japan1 / Korea1, TrueType non symbolique).
Les polices composites Type 0 sont inspectées aux deux couches : /ToUnicode sur le dictionnaire parent Type 0 lui-même, et l'intégration / /CIDToGIDMap sur le premier CIDFont descendant. Les polices Type 3 sautent la vérification d'intégration (leurs glyphes sont des CharProcs en ligne) mais participent toujours à la vérification /ToUnicode.
Les assistants PDFlibPDFA pour un travail de polices similaire n'ont volontairement pas été partagés — une demi-douzaine de routines courtes (suppression de préfixe de sous-ensemble, table de noms Standard-14, présence de FontFile, drapeau Symbolic) sont dupliquées localement comme assistants UA* afin que l'audit PDF/A puisse continuer d'évoluer sans casser PDF/UA, et vice versa.

v3.56.2 2026-05-23

L'audit PDF/UA-1 gagne cinq vérifications ISO 14289-1 supplémentaires couvrant les annotations, fichiers intégrés et contenu optionnel. 10015 signale les annotations Link auxquelles manque une description alternative /Contents non vide (§7.18.5) afin que les lecteurs d'écran puissent annoncer les cibles de lien. 10016 et 10017 signalent les dictionnaires FileSpec de fichier intégré auxquels manquent les clés requises de nom de fichier /F ou /UF (§7.11). 10018 signale les dictionnaires de configuration de contenu optionnel qui omettent une chaîne de texte /Name non vide (§7.10). 10019 signale les dictionnaires de configuration de contenu optionnel qui contiennent la clé interdite /AS (§7.10).
Le parcours d'annotations par page qui alimentait déjà les vérifications TrapNet et /Tabs /S collecte désormais également les données Link / /Contents dans la même passe, gardant l'audit en O(N) sur le nombre d'objets.

v3.56.1 2026-05-23

L'audit PDF/UA-1 gagne cinq nouvelles vérifications ISO 14289-1. 10010 vérifie l'autorisation d'extraction pour accessibilité (bit 10 de la clé /P de chiffrement) sur les fichiers chiffrés (§7.16). 10011 détecte les formulaires XFA dynamiques via l'élément <dynamicRender>required</dynamicRender> à l'intérieur du paquet XFA XDP (§7.15). 10012 signale les Form XObjects qui portent une entrée /Ref — les XObjects de référence sont interdits (§7.20). 10013 signale les annotations TrapNet (§7.18.2). 10014 parcourt chaque page et signale toute page portant des annotations dont le dictionnaire de page ne définit pas /Tabs /S (§7.18.3) afin que l'ordre de tabulation suive l'arbre de structure.
Les cinq nouveaux codes passent par la même paire de handles CheckFileCompliance + GetStringListItem ajoutée dans la version précédente — il n'y a pas de nouvelle surface d'API publique.

v3.56.0 2026-05-23

Nouvel audit côté reader CheckCompliancePDFUA valide un PDF externe contre ISO 14289-1 (PDF/UA-1). Il complète la vérification côté writer existante GetPDFUADiagnostics en acceptant tout PDF d'entrée (sortie propre, sortie de scanner, contenu tiers) et en listant les violations PDF/UA-1 de la même manière que CheckFileCompliance signale déjà les problèmes PDF/A.
CheckFileCompliance accepte désormais ComplianceTest = 2 pour exécuter le nouvel audit PDF/UA-1. Le test PDF/A sous ComplianceTest = 1 est inchangé, et la liste d'incidents transite toujours via la paire de handles existante GetStringListCount / GetStringListItem.
La première mouture couvre les portes de conformité PDF/UA-1 fondamentales du §5 (identification XMP pdfuaid:part) et du §7.1 (flux /Metadata du catalogue, marqueur tagged-PDF, arbre de structure, préférence de titre de visionneuse, langue du document, XMP dc:title, valeur /Suspects, et l'interdiction de remapper les balises de structure standard). Huit codes de diagnostic sont émis — 10001 à 10009 — gardant la plage numérique visuellement séparée des codes PDF/A 00xxx.
Les clauses PDF/UA-1 plus profondes (sécurité, annotations, XObjects, sous-ensemble de polices) sont suivies pour des versions correctives ultérieures sur le même cadre d'audit.

v3.55.6 2026-05-22

Chaque paquet XMP nouvellement généré porte désormais une propriété xmpMM:InstanceID au format uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. L'identifiant est généré via Win32 CoCreateGuid et donne à chaque document produit une empreinte unique et indépendante de la version comme recommandé par ISO 19005-1 §6.7.2 (Cor2) et les guides de bonnes pratiques PDF/A. Les builds non Windows (où le paquet XMP reste vide) ne sont pas affectés.
L'espace de noms xmpMM (http://ns.adobe.com/xap/1.0/mm/) fait désormais partie des SelectionNamespaces du paquet XMP ; les nouveaux assistants SetXMPMM et GenerateInstanceID sous-tendent l'émission d'InstanceID et fournissent la base pour le futur support xmpMM:History / xmpMM:DerivedFrom.
Le schéma de description PDF/A Extension Schema (pdfaExtension / pdfaSchema / pdfaProperty / pdfaType / pdfaField) n'est pas ajouté dans cette version. La création d'un schéma d'extension personnalisé nécessite une construction multi-étape de propriétés bag / seq / structurées au-delà de la forme actuelle SetDublinCore / SetXMPBasic ; le travail est suivi pour une version future. Les documents qui ont besoin de déclarer des propriétés XMP personnalisées continuent à se replier sur le chemin LoadFromString.

v3.55.5 2026-05-22

Les documents PDF/A ont désormais leurs drapeaux /F d'annotation normalisés au moment de l'enregistrement. ISO 19005-1 §6.5.3 requiert que le bit Print soit 1 et les bits Hidden / Invisible / NoView soient 0 sur chaque annotation ; le writer applique désormais ce masque au moment de l'enregistrement afin que les appelants n'aient pas à se rappeler la disposition des bits. Le cas /Subtype /Popup est exempté — les popups sont enfants d'autres annotations et traditionnellement non imprimés.
Le drapeau AcroForm /NeedAppearances est désormais forcé à false au moment de l'enregistrement lorsque le document est dans tout mode PDF/A. ISO 19005-1 §6.9 requiert que le drapeau soit absent ou false ; précédemment le writer laissait la valeur que l'appelant avait définie, ce qui produisait des documents qui demandaient à la visionneuse de régénérer les apparences à l'ouverture et violait silencieusement la spécification lorsque l'appelant l'avait défini à true. La correction s'exécute également pour les documents qui avaient précédemment le drapeau absent — le writer émet un /NeedAppearances false explicite pour ne laisser aucune ambiguïté au validateur.

v3.55.4 2026-05-22

AddStandardFont rejette désormais les appels en mode PDF/A. ISO 19005-1 §6.3.4 révoque l'exemption « Standard 14 peut être non intégrée » de la référence PDF : chaque programme de police dans un fichier conforme doit être intégré, et la bibliothèque ne fournit pas les contours Standard 14. La façade retourne 0 silencieusement ; les appelants doivent passer à AddTrueTypeFont ou AddType1Font avec un vrai fichier de police.
AddTrueTypeFont promeut désormais silencieusement Embed=0 (pas d'intégration) en Embed=1 (intégrer la police complète) lorsque le mode PDF/A est actif. Le chemin de référence non intégré produisait un PDF qui dépendait du repli de police de la visionneuse sur une installation système Arial / Times / Courier, ce qui viole ISO 19005-1 §6.3.4. Les appelants existants qui ont demandé l'intégration (Embed=1 ou 2) ne sont pas affectés.
La vérification de conformité d'encodage TrueType non symbolique (ISO 19005-1 §6.3.7 Cor2 requiert WinAnsi ou MacRoman comme nom d'encodage ou BaseEncoding, sans /Differences) n'est pas ajoutée dans cette version car la bibliothèque émet déjà /WinAnsiEncoding pour les sous-ensembles TrueType non symboliques, et l'application plus profonde nécessiterait de suivre le dispatch symbolique-vs-non-symbolique à travers le chemin de sous-ensemble. CheckCompliancePDFA 00034 / 00035 (ajouté en v3.51.0) signale toute sortie non conforme au moment de la validation.

v3.55.3 2026-05-22

Les dictionnaires de police CIDFontType2 soutenus par TrueType portent désormais /CIDToGIDMap /Identity explicitement. ISO 19005-1 §6.3.3.2 (Cor2) requiert que l'entrée soit présente pour chaque CIDFont Type 2 intégré ; la référence PDF permet le défaut Identity implicite, mais PDF/A exige une valeur explicite. Le writer omettait précédemment entièrement la clé, amenant veraPDF (et CheckCompliancePDFA 00033 ajouté en v3.51.0) à signaler le fichier. Le nom /Identity correspond à la disposition GID-comme-CID que le writer produisait déjà implicitement, donc les documents existants se rendent à l'identique.
FontDescriptor /CharSet (pour les sous-ensembles Type 1) et /CIDSet (pour les sous-ensembles CIDFont) restent TODO ; le writer aurait besoin de suivre quels noms de glyphes / CID se sont retrouvés dans le sous-ensemble pour les remplir avec précision. CheckCompliancePDFA 00031 et 00032 (également ajoutés en v3.51.0) signaleront l'absence afin que les utilisateurs voient le problème au moment de la validation.

v3.55.2 2026-05-22

AddImageDirectFromString rejette désormais les filtres incompatibles avec PDF/A au point d'entrée. Passer Filter = 'LZWDecode' est rejeté pour chaque partie PDF/A (ISO 19005-1 §6.1.10 plus les règles équivalentes ISO 19005-2 / -3). Passer Filter = 'JBIG2Decode' ou 'JPXDecode' est rejeté pour PDF/A-1 (modes 1 et 2). PDF/A-2 et PDF/A-3 admettent JPXDecode sous ISO 19005-2 §6.2.8.3 avec des contraintes de sous-spécification (nombre de canaux de couleur, uniformité de profondeur de bits, exigences METH/APPROX) que la porte côté writer n'applique pas — les appelants dans ces modes doivent encore s'assurer que le flux JPEG 2000 est conforme. La façade retourne 0 silencieusement lorsqu'un filtre interdit est demandé.
Les entrées TIFF, PNG, JPEG et JPEG 2000 chargées via AddImageFromFile / AddImageFromStream ne sont pas affectées : l'importeur décompresse les octets source et ré-encode avec FlateDecode (ou DCTDecode pour les charges utiles JPEG), donc l'entrée LZW ne se propage jamais à la chaîne Filter de sortie. Le validateur CheckCompliancePDFA ajouté en v3.50.0 (00004) et v3.52.0 (00022, 00023) fournit une seconde ligne de défense au moment de la validation pour tout chemin indirect qui glisserait encore un filtre interdit dans la sortie.

v3.55.1 2026-05-22

AddLinkToHideField rejette désormais les appels en mode PDF/A. La version précédente laissait un commentaire affirmant que l'action était compatible PDF/A, mais ISO 19005-1 Cor2 a ajouté /Hide à la liste d'actions interdites (§6.6.1), et ISO 19005-2 / -3 héritent de la restriction. La façade retourne 0 silencieusement lorsqu'appelée en mode PDF/A, correspondant à AddLinkToJavaScript et AddLinkToImportData.
AddSWFAnnotationFromFile rejette désormais les appels en mode PDF/A. Les annotations SWF / RichMedia enveloppent des médias Flash qui sont interdits par ISO 19005-1 §6.5.2 (pas de sous-types Movie / Sound) et renforcés par ISO 19005-2 §6.3.1 (pas de 3D / Sound / Screen / Movie). La façade retourne 0 silencieusement.
AddEmbeddedFile et AddLinkToEmbeddedFile rejettent désormais les appels en modes PDF/A-1 et PDF/A-2. ISO 19005-1 §6.1.11 interdit /EF, et ISO 19005-2 §6.8 n'admet que les fichiers PDF/A intégrés ; plutôt que de vérifier la PDF/A-ité récursive de la charge utile attachée, le writer refuse simplement l'appel dans ces modes. PDF/A-3 (SetPDFAMode 5 ou 6) reste autorisé — voir v3.55.0 pour l'injection automatique /AFRelationship.
SetOpenActionMenu rejette désormais les valeurs MenuItem en dehors de la liste blanche {NextPage, PrevPage, FirstPage, LastPage} lorsque le document est en mode PDF/A. ISO 19005-1 §6.6.1 restreint les actions nommées à cet ensemble, donc précédemment l'API produisait silencieusement des dictionnaires d'Open-Action Find / Print / FullScreen non conformes que veraPDF rejetterait.
NewOptionalContentGroup rejette désormais les appels en modes PDF/A-1 (SetPDFAMode 1 ou 2). ISO 19005-1 §6.1.13 interdit la clé /OCProperties du catalogue. PDF/A-2 (modes 3/4) et PDF/A-3 (modes 5/6) admettent du contenu optionnel avec les contraintes de leurs §6.9 respectifs, donc la porte ne se déclenche que pour PDF/A-1.

v3.55.0 2026-05-22

Les documents PDF/A-3 reçoivent désormais automatiquement une entrée /AFRelationship sur chaque fichier intégré. Précédemment un fichier PDF/A-3 créé avec la bibliothèque pouvait échouer à la validation car ISO 19005-3 Annexe E, Table E.1 requiert AFRelationship sur chaque spécification de fichier intégré. Le writer injecte désormais la valeur par défaut configurée ('Unspecified' par défaut) sur tout dictionnaire FileSpec auquel manque l'entrée au moment de l'enregistrement, reproduisant l'auto-injection AFRelationship PDF/UA introduite plus tôt. Seuls les modes PDF/A-3 (SetPDFAMode 5 = PDF/A-3b ou 6 = PDF/A-3a) déclenchent l'auto-injection ; PDF/A-1 et PDF/A-2 rejettent encore les fichiers intégrés tout court selon ISO 19005-1 §6.1.11 et ISO 19005-2 §6.8.
SetPDFA3DefaultAFRelationship est une nouvelle API qui remplace la valeur par défaut écrite par le writer lorsqu'un fichier intégré manque d'entrée /AFRelationship. Accepte les valeurs ISO 19005-3 Table E.1 'Source' (le fichier intégré est le matériel source qui a produit le contenu PDF), 'Data' (le fichier est les données structurées supportant un tableau ou graphique visuel), 'Alternative' (un rendu alternatif tel qu'une version audio), 'Supplement' (une représentation supplémentaire telle qu'une forme MathML d'une équation), 'Unspecified' (la relation ne peut être caractérisée par ce qui précède), ou tout nom de seconde classe enregistré. Une chaîne vide remet à zéro sur 'Unspecified'. Les surcharges par fichier restent disponibles via SetEmbeddedFileAFRelationship.
Les nouvelles API sont exposées sur la façade Delphi sous TPDFlib.SetPDFA3DefaultAFRelationship et via la DLL sous DLSetPDFA3DefaultAFRelationship (PWideChar) et DLSetPDFA3DefaultAFRelationshipA (PAnsiChar).

v3.54.0 2026-05-22

LoadOutputIntentProfile est une nouvelle API qui remplace le profil OutputIntent sRGB fourni par un profil ICC externe chargé depuis le disque. Requis lors de la production de documents PDF/A dans les espaces de couleur DeviceCMYK ou DeviceGray, puisque la bibliothèque ne livre qu'un profil sRGB. L'utilisation typique est d'appeler d'abord SetPDFAMode (qui initialise le squelette OutputIntent), puis LoadOutputIntentProfile('C:\\path\\to\\FOGRA39.icc', 'DeviceCMYK') pour échanger les octets du profil et marquer le document avec le nouvel espace de couleur. Retourne 1 en cas de succès, 0 si fichier introuvable ou espace de couleur inconnu. Exposé sur la façade Delphi sous TPDFlib.LoadOutputIntentProfile et via la DLL sous DLLoadOutputIntentProfile (forme PWideChar) et DLLoadOutputIntentProfileA (forme PAnsiChar). ISO 19005-1 §6.2.2 autorise tout profil ICC enregistré dans le flux DestOutputProfile.
SetFillColorCMYK, SetTextColorCMYK, SetTextHighlightColorCMYK, SetTextUnderlineColorCMYK, AddSeparationColor, SetFillColorSep, SetLineColorSep, SetTextHighlightColorSep et SetTextColorSep réussissent désormais en mode PDF/A lorsque le profil OutputIntent du document est DeviceCMYK. Précédemment ces API rejetaient chaque appel en mode PDF/A quel que soit l'OutputIntent, ce qui empêchait de produire des documents CMYK conformes. La porte est désormais PDFAMode = 0 OU OutputIntentColorSpace = 'DeviceCMYK', correspondant à la règle ISO 19005-1 §6.2.3.3 selon laquelle DeviceCMYK est permis lorsque l'OutputIntent utilise un profil CMYK, et ISO 19005-1 §6.2.3.4 qui autorise les alternatives Separation dont l'espace de couleur de base est également conforme.
SetTextShader réussit désormais en mode PDF/A lorsque le profil OutputIntent est soit DeviceRGB soit DeviceCMYK. Les shaders eux-mêmes ne sont pas interdits par PDF/A ; le validateur (côté reader) vérifie que l'espace de couleur interne du shader correspond à l'OutputIntent. Le précédent comportement de rejet strict refusait l'utilisation conforme de shader.
Le déblocage CMYK / Separation / Shader dépend de la balise OutputIntentColorSpace définie par AddOutputIntent et LoadOutputIntentProfile (introduits en v3.53.0). Appeler SetPDFAMode sans LoadOutputIntentProfile garde l'espace de couleur comme DeviceRGB (le profil sRGB fourni), donc les appels CMYK rejettent encore par défaut — le nouveau comportement est opt-in via LoadOutputIntentProfile.

v3.53.0 2026-05-22

Le dictionnaire OutputIntent porte désormais les champs squelette PDF/A complets recommandés par ISO 19005-1 §6.2.2 et le preflight Adobe Acrobat : /OutputCondition (description lisible de la condition de couleur), /Info (texte d'identification long), et /RegistryName (URL de registre, par défaut http://www.color.org). Les valeurs par défaut sont "sRGB IEC61966-2.1" / "sRGB IEC61966-2.1" / "http://www.color.org" pour les sites d'appel hérités à argument unique ; la nouvelle surcharge AddOutputIntent prend les quatre champs personnalisés directement afin que les appelants puissent les remplir pour leurs propres conditions de couleur.
AddOutputIntent gagne une nouvelle surcharge à cinq arguments : AddOutputIntent(ColorSpace, OutputConditionIdentifier, OutputCondition, Info, RegistryName). La forme héritée à argument unique continue de fonctionner inchangée ; elle délègue désormais à la nouvelle surcharge avec les défauts sRGB. L'argument ColorSpace sélectionne également le nombre de composants /N écrit dans le dictionnaire de profil ICC intégré (3 pour DeviceRGB, 4 pour DeviceCMYK, 1 pour DeviceGray) ; le profil intégré lui-même reste le flux sRGB fourni jusqu'à ce que la prochaine API LoadOutputIntentProfile arrive en v3.54.0.
TPDFDocument expose OutputIntentColorSpace comme propriété lecture/écriture suivant l'espace de couleur du dernier appel AddOutputIntent. Cela devient la condition de porte pour les restrictions côté writer CMYK / Separation / Shader en v3.54.0, où les API de couleur qui aujourd'hui rejettent chaque appel en mode PDF/A rejetteront uniquement lorsque l'espace de couleur ne correspond pas à l'OutputIntent.

v3.52.0 2026-05-22

CheckCompliancePDFA audite désormais les annotations, l'état graphique, les actions et les Form XObjects, complétant la couverture du validateur PDF/A côté reader des chapitres ISO 19005-1 6.2-6.6 et des règles différentielles équivalentes PDF/A-2/-3. Le validateur signale 14 nouvelles classes d'incidents (00050-00067) : sous-types d'annotation interdits (00050 ; ISO 19005-1 §6.5.2 interdit FileAttachment / Sound / Movie pour PDF/A-1, et ISO 19005-2 §6.3.1 interdit 3D / Sound / Screen / Movie pour PDF/A-2 et PDF/A-3), /CA d'annotation autre que 1.0 (00051 ; §6.5.3), /F d'annotation manquant ou avec Print=0 / Hidden=1 / Invisible=1 / NoView=1 (00052 ; §6.5.3, avec /Subtype /Popup exempté), /AA d'annotation (00054 ; §6.6.2), dictionnaire d'apparence d'annotation avec des clés autres que /N ou valeur /N non conforme (00055 ; §6.5.3 Cor2), annotation Widget avec /A (00056 ; §6.9), ExtGState /TR (00058 ; §6.2.8), ExtGState /TR2 autre que /Default (00059 ; §6.2.8), et en PDF/A-1 uniquement : ExtGState /SMask autre que /None (00061 ; §6.4), /BM autre que Normal ou Compatible (00062 ; §6.4), /CA ou /ca autre que 1.0 (00063 ; §6.4).
L'audit action-partout (00064, 00065) remplace la vérification OpenAction-seulement de v3.50.0 par un balayage complet qui signale les valeurs d'action /S interdites (Launch, Sound, Movie, ResetForm, ImportData, JavaScript, Hide, SetState, NOP, Trans, GoTo3DView, Rendition, SetOCGState) et les actions nommées dont /N est en dehors de {NextPage, PrevPage, FirstPage, LastPage} quel que soit l'endroit où vit l'action (annotation /A, widget /A, outline /A, catalogue /OpenAction, etc.). ISO 19005-1 §6.6.1.
L'audit XObject (00066, 00067) signale les XObjects PostScript et Reference, plus les clés interdites sur les Form XObjects (/OPI, /PS, /Subtype2 = /PS) et les Image XObjects (/Alternates, /OPI, /Interpolate true). ISO 19005-1 §6.2.4 - §6.2.7.

v3.51.0 2026-05-22

CheckCompliancePDFA audite désormais la conformité des polices et des espaces de couleur en plus des vérifications structurelles ajoutées en v3.50.0. Le validateur signale neuf nouvelles classes d'incidents : au moins un programme de police n'est pas intégré (00030 ; ISO 19005-1 §6.3.4 requiert que chaque programme de police, y compris les substitutions Standard 14, soit intégré), sous-ensemble Type 1 sans /CharSet dans son FontDescriptor (00031 ; §6.3.5), sous-ensemble CIDFont sans /CIDSet (00032 ; §6.3.5), CIDFontType2 sans /CIDToGIDMap (00033 ; §6.3.3.2 Cor2), TrueType non symbolique avec un /Encoding non conforme (00034 ; §6.3.7 Cor2 requiert WinAnsi/MacRoman directement ou comme BaseEncoding, sans /Differences), TrueType symbolique qui porte encore /Encoding (00035 ; §6.3.7 Cor2), au moins une police sans /ToUnicode dans les documents PDF/A-Na ou PDF/A-Nu (00036 ; exemption en quatre classes §6.3.8 appliquée), espace de couleur ICCBased qui n'intégre pas son flux de profil (00037 ; §6.2.3.2), et un fichier qui utilise à la fois DeviceRGB et DeviceCMYK (00038 ; §6.2.3.3 interdit le mélange).
La vérification /ToUnicode (00036) est limitée aux niveaux de conformité A et U car seuls ces niveaux requièrent un mappage Unicode selon ISO 19005-1 §6.3.8 et ISO 19005-2 §6.2.11.7. Les fichiers de niveau B (PDF/A-1b, PDF/A-2b, PDF/A-3b) ne sont pas signalés. L'exemption en quatre classes reconnaît les encodages prédéfinis (MacRomanEncoding, MacExpertEncoding, WinAnsiEncoding), les BaseFonts Type 1 Standard 14 comme proxy pour les polices Adobe Standard Latin / Symbol à noms de glyphes, et les polices Type 0 dont le CIDFont descendant utilise les registres Adobe-GB1, Adobe-CNS1, Adobe-Japan1 ou Adobe-Korea1.
L'audit de polices parcourt chaque dictionnaire de police, le classifie par Subtype (Type1, MMType1, TrueType, Type3, Type0 avec son descendant CIDFontType0 ou CIDFontType2), puis dispatche les vérifications pertinentes. Les polices composites Type 0 délèguent les vérifications d'intégration et de sous-ensemble à leur CIDFont descendant tout en gardant /ToUnicode sur l'enveloppe Type 0. La détection de sous-ensemble utilise la convention standard du préfixe de six lettres majuscules.

v3.50.0 2026-05-22

CheckCompliancePDFA signale désormais 15 incidents de non-conformité PDF/A supplémentaires que le validateur omettait précédemment : tableau trailer /ID manquant (00013), flux /Metadata du catalogue de document manquant (00014), /Filter appliqué au flux /Metadata (00015), dictionnaires de flux qui référencent des fichiers externes via /F, /FFilter ou /FDecodeParms (00016), fichiers intégrés déclarés via /EF dans tout dictionnaire de spécification de fichier ou via l'entrée d'arbre de noms /EmbeddedFiles dans les documents PDF/A-1 (00017, 00018), /OpenAction pointant vers un type d'action interdit (00019), dictionnaires d'action additionnelle /AA dans le catalogue de document ou toute page (00020, 00021), filtres JBIG2Decode ou JPXDecode dans les documents PDF/A-1 (00022, 00023), filtres Crypt dont le /Name n'est pas /Identity (00024), /Requirements dans le catalogue de document (00025), /Perms avec des clés autres que /UR3 et /DocMDP (00026), et /AcroForm /NeedAppearances défini à true (00027). Le validateur signale désormais les types d'action /OpenAction de catalogue interdits (/Launch, /Sound, /Movie, /ResetForm, /ImportData, /JavaScript, /Hide, /SetState, /NOP, /Trans, /GoTo3DView, /Rendition, /SetOCGState) et les valeurs /N d'action nommée en dehors de la liste blanche {NextPage, PrevPage, FirstPage, LastPage} selon ISO 19005-1 §6.6.1.
L'analyseur PDFAID accepte le suffixe de conformité U (PDF/A-2U, PDF/A-3U) aux côtés des variantes A et B existantes, donc CheckCompliancePDFA ne lève plus un avertissement fallacieux "00005 PDFA Mark NOT Found or invalid" lors du scan d'un fichier PDF/A-2U ou PDF/A-3U produit par un autre outil. Les niveaux de conformité de mappage Unicode ajoutés en ISO 19005-2:2011 sont désormais reconnus par le validateur.
Les vérifications spécifiques aux filtres (JBIG2Decode, JPXDecode) et les vérifications de fichiers intégrés (/EF, /EmbeddedFiles) restent limitées à PDF/A-1 car ISO 19005-2 §6.2.8.3 et §6.8 relâchent explicitement ces restrictions pour PDF/A-2 et PDF/A-3. Les vérifications de structure de document (/Metadata, /AcroForm /NeedAppearances, /OpenAction, /AA, /Requirements, /Perms) s'appliquent à chaque partie PDF/A.

v3.49.0 2026-05-21

AddLinkToImportData crée une annotation Link dont l'action est une action PDF d'import de données (/S /ImportData) qui remplit les champs AcroForm du document à partir d'un fichier FDF externe lorsque l'utilisateur clique sur le lien (ISO 32000-1 §12.6.4.8, Table 198). Le paramètre FileName est référencé comme un dictionnaire filespec, avec les mêmes règles de normalisation de chemin utilisées par AddLinkToFile / AddLinkToFileEx (les antislashes sont convertis en slashes selon ISO 32000-1 §7.11.2.1). Le bit 0 d'Options active la bordure visible et les bits 1–3 sélectionnent le mode de surbrillance du lien (Invert, Outline, Push), conformément aux conventions existantes AddLinkTo*. PDF 1.4 ou ultérieur. NON autorisé en PDF/A car l'action référence une ressource externe ; la façade retourne silencieusement 0 lorsqu'appelée en mode PDF/A. Exposé dans la bibliothèque Delphi et l'interface DLL sous DLAddLinkToImportData / DLAddLinkToImportDataA (formes PWideChar et PAnsiChar).

v3.48.0 2026-05-21

AddLinkToHideField crée une annotation Link dont l'action est une action PDF de masquage (/S /Hide) basculant la visibilité d'un ou plusieurs champs AcroForm lorsque l'utilisateur clique sur le lien (ISO 32000-1 §12.6.4.10, Table 196). FieldNames accepte un ou plusieurs noms de champs pleinement qualifiés séparés par des virgules, points-virgules ou sauts de ligne ; un nom unique émet /T comme chaîne de texte et deux noms ou plus émettent /T comme tableau, les deux formes étant autorisées par la spécification. HideFlag sélectionne le sens de visibilité : une valeur non nulle masque les champs listés (/H true) et zéro les affiche (/H false). Le bit 0 d'Options active la bordure visible et les bits 1–3 sélectionnent le mode de surbrillance du lien (Invert, Outline, Push), conformément à AddLinkToWeb / AddLinkToNamedAction. PDF 1.2 ou ultérieur. Compatible PDF/A car aucune ressource externe n'est référencée. Exposé dans la bibliothèque Delphi et l'interface DLL sous DLAddLinkToHideField / DLAddLinkToHideFieldA (formes PWideChar et PAnsiChar).

v3.47.0 2026-05-21

AddLinkToNamedAction crée une annotation Link dont l'action est une action nommée PDF (/S /Named) déclenchant l'une des quatre commandes standard de navigation de visionneuse définies dans ISO 32000-1 §12.6.4.11, Table 194 : NextPage, PrevPage, FirstPage et LastPage. Le paramètre NamedActionType sélectionne la commande (0=NextPage, 1=PrevPage, 2=FirstPage, 3=LastPage) ; les valeurs hors de cet intervalle se replient sur NextPage afin que le writer émette toujours un nom /N conforme à la spécification. Le bit 0 d'Options active la bordure visible et les bits 1–3 sélectionnent le mode de surbrillance du lien (Invert, Outline, Push), conformément aux conventions existantes AddLinkToWeb / AddLinkToPage. L'annotation requiert PDF 1.1 ou ultérieur et est compatible avec PDF/A car aucune ressource externe n'est référencée. Disponible dans la bibliothèque Delphi et les interfaces DLL.

v3.46.1 2026-05-21

AddCaretAnnotation crée une annotation de balisage caret (PDF /Subtype /Caret) au rectangle donné, marquant une position sur la page où du texte ou contenu a été inséré, omis ou requiert l'attention du réviseur. Prend en charge deux types de symboles (None et Paragraph) via SymbolType (0 / 1), couleur configurable, opacité, titre, contenu et horodatages de création/modification. Définie dans ISO 32000-1 §12.5.6.11. PDF 1.5 ou ultérieur. Disponible dans la bibliothèque Delphi et les interfaces DLL.
Cette entrée achève le rattrapage des annotations géométriques qui a commencé avec v3.44.0 Square+Circle. PDFlibPas crée désormais des annotations Text, Stamp, FreeText, TextMarkup (Highlight/Underline/Squiggly/StrikeOut), Square, Circle, Line, Polygon, PolyLine, Ink et Caret, en plus du support existant pour Link, FileAttachment, SVG, U3D et SWF.

v3.46.0 2026-05-21

AddInkAnnotation crée une annotation de balisage encre (PDF /Subtype /Ink) représentant des traits manuscrits ou marques à main levée dessinées sur la page. Les traits sont fournis comme une chaîne unique où plusieurs traits sont séparés par '|' ou retour à la ligne, et à l'intérieur de chaque trait les paires de coordonnées suivent le même format espace/virgule/point-virgule/tabulation utilisé par AddPolygonAnnotation. Par exemple "100 100 110 105 120 110 | 200 200 210 205" décrit deux traits séparés. Prend en charge largeur de bordure configurable, couleur d'encre, opacité, titre, contenu et horodatages. Définie dans ISO 32000-1 §12.5.6.13. PDF 1.3 ou ultérieur. Disponible dans la bibliothèque Delphi et les interfaces DLL.
Chaque trait doit contenir un nombre pair de valeurs (au moins quatre), sinon l'appel retourne 0 sans écrire d'annotation. Le /Rect est calculé automatiquement à partir de l'étendue combinée de tous les traits plus un petit espacement afin que les traits restent à l'intérieur de la boîte englobante de l'annotation.

v3.45.0 2026-05-21

AddPolygonAnnotation crée une annotation de balisage polygone fermé (PDF /Subtype /Polygon) avec des sommets fournis comme une chaîne de paires de coordonnées séparées par espaces, virgules, points-virgules ou tabulations (par ex. "100 100 200 100 200 200 100 200"). Prend en charge largeur de bordure configurable, couleur de bordure, couleur de remplissage intérieur optionnelle, opacité, titre, contenu et horodatages. Définie dans ISO 32000-1 §12.5.6.9. PDF 1.5 ou ultérieur. Disponible dans la bibliothèque Delphi et les interfaces DLL.
AddPolyLineAnnotation crée une annotation de balisage polyligne ouverte (PDF /Subtype /PolyLine) avec le même format de chaîne de sommets et des styles d'extrémité de ligne configurables à chaque terminaison (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash). Définie dans ISO 32000-1 §12.5.6.9. PDF 1.5 ou ultérieur. Disponible dans la bibliothèque Delphi et les interfaces DLL.
Les deux annotations requièrent au moins deux sommets (quatre nombres) et un nombre total pair de valeurs ; l'appel retourne 0 si la chaîne de sommets ne peut être analysée en une liste de paires valide. Le /Rect est calculé à partir de l'étendue des sommets plus un espacement proportionnel à la largeur de bordure afin que les décorations d'extrémité restent visibles.
Les deux annotations élèvent la version du document à PDF 1.5 lorsqu'elles sont émises sous un verrou de version minimum inférieur.

v3.44.1 2026-05-21

AddLineAnnotation crée une annotation de balisage ligne (PDF /Subtype /Line) entre deux extrémités, avec largeur de bordure configurable, couleur de ligne, couleur de remplissage intérieur optionnelle, styles d'extrémité de ligne pour les deux extrémités (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash), opacité, titre, contenu et horodatages de création/modification. Définie dans ISO 32000-1 §12.5.6.7. PDF 1.3 ou ultérieur. Disponible dans la bibliothèque Delphi et les interfaces DLL.
Le /Rect de l'annotation est calculé à partir des deux extrémités plus un espacement proportionnel à la largeur de bordure afin que les décorations d'extrémité restent à l'intérieur de la boîte englobante de l'annotation.

v3.44.0 2026-05-21

AddSquareAnnotation crée une annotation de balisage rectangle (PDF /Subtype /Square) au rectangle donné, avec largeur de bordure configurable, couleur de bordure, couleur de remplissage intérieur optionnelle, opacité, titre, contenu et horodatages de création/modification. Définie dans ISO 32000-1 §12.5.6.8. PDF 1.3 ou ultérieur. Disponible dans la bibliothèque Delphi et les interfaces DLL.
AddCircleAnnotation crée une annotation de balisage ellipse (PDF /Subtype /Circle) inscrite dans le rectangle donné, avec les mêmes bordure, remplissage, opacité, titre, contenu et horodatages configurables que AddSquareAnnotation. Définie dans ISO 32000-1 §12.5.6.8. PDF 1.3 ou ultérieur. Disponible dans la bibliothèque Delphi et les interfaces DLL.
Les deux nouvelles annotations élèvent automatiquement la version du document à PDF 1.3 lorsqu'elles sont émises sous un verrou de version minimum inférieur et émettent un ensemble standard de champs d'annotation de balisage (/Type /Subtype /Rect /C /IC /BS /Border /CA /F /M /CreationDate /NM /T /Contents /Subj /P) afin que les workflows de relecture existants dans Acrobat, Foxit et Edge puissent les modifier après création.

v3.43.0 2026-05-20

SetStructElemSpaceBefore et SetStructElemSpaceAfter définissent les attributs /SpaceBefore et /SpaceAfter (propriétaire Layout) sur l'élément de structure actuellement ouvert, exprimant l'espacement avant et après les éléments de niveau bloc en points. Définis dans ISO 32000-1 §14.8.5.4.2 Table 340. Disponibles dans la bibliothèque Delphi, ActiveX (Dispids 73008051/73008052) et les interfaces DLL.
SetStructElemStartIndent et SetStructElemEndIndent définissent les attributs /StartIndent et /EndIndent (propriétaire Layout), exprimant l'indentation depuis les bords de début et de fin du rectangle de contenu, sensibles au mode d'écriture, en points. Définis dans ISO 32000-1 §14.8.5.4.2 Table 340. Disponibles dans la bibliothèque Delphi, ActiveX (Dispids 73008053/73008054) et les interfaces DLL.
SetStructElemColor définit l'attribut /Color (propriétaire Layout) comme un triplet RVB (chaque composante 0.0-1.0), décrivant la couleur de premier plan de l'élément pour les moteurs de redistribution et les vérificateurs de contraste de couleur en aval. Défini dans ISO 32000-1 §14.8.5.4.2 Table 340. Disponible dans la bibliothèque Delphi, ActiveX (Dispid 73008055) et les interfaces DLL.
Correction d'un bogue de sérialisation dans BuildStructElemDictRef : les valeurs d'attribut numériques à jeton unique (telles que SpaceBefore, SpaceAfter, StartIndent, EndIndent) étaient écrites comme des noms PDF au lieu de nombres PDF. La correction s'applique aux branches d'attribut à propriétaire unique comme à propriétaires multiples.

v3.42.0 2026-05-20

CheckCompliancePDFA valide désormais correctement les six modes PDF/A (1a, 1b, 2a, 2b, 3a, 3b). La vérification PDFAID (code 00005) accepte n'importe lequel des six marqueurs XMP valides au lieu de seulement '1B'. La vérification de plafond de version (00002) applique 1.4 pour PDF/A-1 et 1.7 pour PDF/A-2 et PDF/A-3.
La vérification OCProperties (code 00003) est désormais conditionnelle : elle ne s'applique qu'aux documents PDF/A-1, où le contenu optionnel (calques) est interdit. PDF/A-2 et PDF/A-3 autorisent les calques et ne sont plus signalés.
Trois nouvelles vérifications de conformité ajoutées : le code 00006 signale les documents chiffrés (le chiffrement est interdit dans toutes les versions PDF/A) ; le code 00007 signale les documents auxquels manque une entrée OutputIntents dans le catalogue (requise par toutes les versions PDF/A) ; les codes 00011 et 00012 signalent les documents auxquels manque MarkInfo ou StructTreeRoot lorsque le niveau de conformité est -a (accessibilité).

v3.41.0 2026-05-20

Le mode PDF/A impose désormais les opérations interdites au niveau de l'API. Lorsqu'un mode PDF/A est actif (l'un quelconque des modes 1-6), les appels à SetEncryption, AddSeparationColor, SetFillColorCMYK, SetTextColorCMYK ou toute autre API CMYK/Separation/Shader retournent 0 et n'ont aucun effet, conformément à l'exigence PDF/A d'un seul output intent sRGB.
La transparence est interdite en PDF/A-1 (modes 1 et 2) : SetTransparency, SetBlendMode et SetPageTransparencyGroup retournent 0 et sont sans effet lorsque le mode actif est 1 ou 2. PDF/A-2 et PDF/A-3 (modes 3-6) autorisent une transparence limitée et ne sont pas restreints.
Les actions JavaScript sont interdites dans tous les modes PDF/A (1-6) : SetOpenActionJavaScript, PageJavaScriptAction, DocJavaScriptAction, AddGlobalJavaScript et AddLinkToJavaScript retournent tous 0 et sont sans effet lorsqu'un mode PDF/A est actif. ISO 19005-1 §6.6.1 interdit explicitement JavaScript dans les documents PDF/A.
Les API de pièces jointes (EmbedFile, AddFileAttachment) sont bloquées dans les modes PDF/A-1 et PDF/A-2 (1-4). Elles restent fonctionnelles dans PDF/A-3 (modes 5 et 6), qui autorise explicitement des fichiers intégrés arbitraires.

v3.40.0 2026-05-20

SetPDFAMode prend désormais en charge les niveaux de conformité PDF/A-2 et PDF/A-3. Passer NewMode=3 pour PDF/A-2b, 4 pour PDF/A-2a, 5 pour PDF/A-3b ou 6 pour PDF/A-3a. PDF/A-2 vise PDF 1.7 et autorise les calques, formulaires interactifs, images JPEG2000 et transparence limitée. PDF/A-3 étend PDF/A-2 en autorisant des fichiers intégrés arbitraires (tout type MIME). Toutes les variantes -a écrivent automatiquement /MarkInfo et les marqueurs de structure tagged-PDF requis par le niveau de conformité d'accessibilité.
Corrigé : SetPDFAMode(1) (PDF/A-1a) était précédemment sans effet en raison d'un bogue de routage interne introduit en v3.20.0. Il écrit désormais correctement /MarkInfo et /OutputIntents et définit XMP pdfaid:part=1/conformance=A.
GetInformation(201) retourne '1' à '6' correspondant au mode PDF/A actif, conformément à la nouvelle numérotation des modes.

v3.39.0 2026-05-20

SetStructElemWritingMode définit l'attribut /WritingMode (propriétaire Layout) sur l'élément de structure actuellement ouvert. Les valeurs valides sont LrTb (de gauche à droite, par défaut pour les écritures latines), RlTb (de droite à gauche, pour l'arabe et l'hébreu) et TbRl (de haut en bas, de droite à gauche, pour le texte vertical CJK traditionnel). Défini dans ISO 32000-1 §14.8.5.4.2 Table 340. Disponible dans la bibliothèque Delphi, ActiveX (Dispid 73008049) et les interfaces DLL.
SetStructElemListNumbering définit l'attribut /ListNumbering (propriétaire List) sur l'élément de structure actuellement ouvert. Les valeurs prises en charge incluent None, Disc, Circle, Square (marqueurs non ordonnés) et Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha (numérotation ordonnée). L'attribut est défini sur l'élément L (list) et permet aux technologies d'assistance d'annoncer correctement le type de liste. Défini dans ISO 32000-1 §14.8.5.3.2 Table 336. Disponible dans la bibliothèque Delphi, ActiveX (Dispid 73008050) et les interfaces DLL.

v3.38.0 2026-05-20

SetStructElemColSpan définit l'attribut /ColSpan (propriétaire Table) sur l'élément de structure actuellement ouvert, indiquant sur combien de colonnes la cellule s'étend. Défini dans ISO 32000-1 §14.8.5.7.2 Table 337. Disponible dans la bibliothèque Delphi, ActiveX (Dispid 73008047) et les interfaces DLL.
SetStructElemRowSpan définit l'attribut /RowSpan (propriétaire Table) sur l'élément de structure actuellement ouvert, indiquant sur combien de lignes la cellule s'étend. Défini dans ISO 32000-1 §14.8.5.7.2 Table 337. Disponible dans la bibliothèque Delphi, ActiveX (Dispid 73008048) et les interfaces DLL.
Les deux fonctions sont des wrappers de commodité équivalents à l'appel à AddTagAttribute avec Owner='Table' et le nom d'attribut respectif. Elles complètent SetStructElemScope pour des cellules de tableau pleinement décrites dans des tableaux complexes ou à en-têtes étendus.

v3.37.2 2026-05-20

GetPDFUADiagnostics signale désormais FORM-NO-TOOLTIP:N lorsque N champs de formulaire interactifs (annotations Widget) ne disposent pas d'une entrée TU (info-bulle / nom accessible). ISO 14289-1 §7.18.4 requiert que tous les champs de formulaire interactifs portent une entrée TU afin que les technologies d'assistance puissent annoncer le but du champ à l'utilisateur lorsque le champ reçoit le focus. /TU est le nom accessible que les lecteurs d'écran prononcent à voix haute ; il est distinct de /T, qui est le nom partiel de champ utilisé pour l'accès programmatique et la soumission de formulaire.

v3.37.1 2026-05-20

GetPDFUADiagnostics signale désormais LIST-STRUCT:N lorsque N éléments de structure LI ou LBody apparaissent en dehors de leur élément parent requis. ISO 32000-1 §14.8.4.4 requiert que LI soit un enfant direct de L (liste) et que LBody soit un enfant direct de LI (élément de liste). Une imbrication de listes mal formée empêche les technologies d'assistance de parcourir et annoncer correctement le contenu de la liste, et peut provoquer des échecs de validation de structure de document dans les validateurs PDF/UA-1.

v3.37.0 2026-05-20

BeginTagEx2 est une nouvelle API qui ouvre un élément de structure et définit toutes les propriétés principales de l'élément en un seul appel. En plus des paramètres TagType, AltText, ActualText et Lang de BeginTagEx, BeginTagEx2 accepte Title (/T, pour le panneau de navigation Tags), ElemID (/ID, identifiant unique de l'élément) et Expansion (/E, texte complet d'une abréviation ou d'un acronyme). Passer une chaîne vide pour l'un quelconque de ces trois paramètres additionnels équivaut à omettre le setter correspondant. BeginTagEx2 réduit le code passe-partout pour les éléments bien décrits — plutôt que d'appeler BeginTagEx suivi de SetStructElemTitle, SetStructElemID et SetStructElemExpansion séparément, toutes les sept propriétés peuvent être définies en un seul appel. La fonction est disponible dans la bibliothèque Delphi, ActiveX (Dispid 73008046) et les interfaces DLL.

v3.36.1 2026-05-20

GetPDFUADiagnostics signale désormais TABLE-TH-NO-SCOPE:N lorsque N éléments de structure TH (cellules d'en-tête de tableau) sont dépourvus d'attribut Scope. ISO 32000-1 §14.8.4.3.4 Table 337 définit Scope (Row, Column ou Both) comme l'attribut qui décrit à quelles cellules de données une cellule d'en-tête s'applique. Sans lui, les lecteurs d'écran et autres technologies d'assistance ne peuvent pas associer de façon fiable les cellules d'en-tête aux cellules de données dans des tableaux complexes ou multi-en-têtes, ce qui est requis par ISO 14289-1 §7.5. Appelez SetStructElemAttr('Table','Scope', 'Column') (ou 'Row' / 'Both') immédiatement après avoir balisé chaque élément TH.

v3.36.0 2026-05-20

SetStructElemExpansion est une nouvelle API qui définit l'entrée /E (texte d'expansion) sur l'élément de structure actuellement ouvert (ISO 32000-1 §14.9.5). Le texte d'expansion est la forme pleinement épelée d'une abréviation ou d'un acronyme contenu dans l'élément — par ex. "World Wide Web" pour un Span dont le texte est "WWW". Les lecteurs d'écran prononcent l'expansion au lieu de tenter de prononcer les caractères abrégés, ce qui est essentiel pour l'accessibilité des contenus techniques et scientifiques. PDF/UA-1 (ISO 14289-1 §7.2) requiert que la langue naturelle soit déterminable sans ambiguïté ; /E est le mécanisme standard pour les abréviations et acronymes. La fonction est disponible dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.35.1 2026-05-20

GetPDFUADiagnostics signale désormais DOCINFO-TITLE-MISSING lorsque l'entrée /Title du dictionnaire d'information du document est absente ou vide. PDF/UA-1 (ISO 14289-1) requiert un titre de document afin que les lecteurs d'écran puissent l'annoncer lorsque le document est ouvert. La vérification existante DISPLAYDOCTITLE-FALSE confirme que le titre est affiché dans la barre de titre de la visionneuse ; DOCINFO-TITLE-MISSING est complémentaire — elle confirme que la valeur de titre elle-même est définie. Appelez SetDocumentInfo('Title', ...) pour fournir la valeur.

v3.35.0 2026-05-20

SetStructElemTitle est une nouvelle API qui définit l'entrée /T (titre) sur l'élément de structure actuellement ouvert (ISO 32000-1 §14.7.2 Table 324). Le titre est une étiquette lisible par un humain qui identifie l'instance spécifique de l'élément — par exemple "Chapter 1", "Summary Table" ou "Figure 3: Quarterly Sales" — et est affiché dans le panneau de navigation Tags des visionneuses PDF et utilisé par les outils de remédiation d'accessibilité. /T est distinct de /Alt (texte alternatif pour les utilisateurs avec déficience de rendu) et /ActualText (correction de texte au niveau glyphe) ; il est le plus utile sur des éléments conteneurs non textuels tels que Table, Figure, Form, Sect et Div. Passez une chaîne vide pour effacer une valeur précédemment définie. La fonction est disponible dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.34.0 2026-05-20

SetStructElemAltText est une nouvelle API qui définit l'entrée /Alt sur l'élément de structure actuellement ouvert (ISO 32000-1 §14.9.3). Elle équivaut à passer AltText à BeginTag mais permet de définir ou mettre à jour la description de texte alternatif après que l'élément a été ouvert — utile lorsque la description est calculée séparément du type d'élément. PDF/UA-1 (ISO 14289-1 §7.5) requiert un texte Alt sur les éléments Figure et Formula ; GetPDFUADiagnostics signale déjà FIGURE-NO-ALT:N pour les valeurs manquantes. La fonction est disponible dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.33.1 2026-05-20

GetPDFUADiagnostics inclut désormais une vérification ROLEMAP-UNMAPPED:N qui détecte les noms de type d'élément de structure personnalisés utilisés dans le document mais sans entrée dans le dictionnaire /RoleMap. ISO 14289-1 §7.1 et ISO 32000-1 §14.7.3 requièrent que chaque type de structure non standard soit mappé sur un type PDF standard (tel que P, Span ou Figure) afin que les technologies d'assistance puissent déterminer comment traiter l'élément. Lorsque N types non mappés sont trouvés, la description de l'incident inclut la liste des noms de type afin que les appelants sachent quelles entrées AddRoleMap sont nécessaires. Tous les 49 types de structure standard définis dans ISO 32000-1 Table 333 (PDF 1.7) sont reconnus et exclus du rapport.

v3.33.0 2026-05-20

SetStructElemLang est une nouvelle API qui définit l'entrée /Lang sur l'élément de structure actuellement ouvert (ISO 32000-1 §14.9.2). La balise de langue remplace la langue au niveau document déclarée par SetDocumentLanguage ou SetPDFUAMode pour l'élément et tous ses descendants, permettant aux documents multilingues de marquer chaque portion avec sa balise de langue BCP 47 correcte (par ex. 'en-US', 'fr', 'zh-Hant-TW'). Les lecteurs d'écran utilisent le /Lang au niveau élément pour sélectionner le moteur de synthèse vocale ou la voix appropriée lors de la lecture du document à voix haute. La fonction est disponible dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.32.0 2026-05-20

SetStructElemActualText est une nouvelle API qui définit l'entrée /ActualText sur l'élément de structure actuellement ouvert (ISO 32000-1 §14.9.4). Utilisez-la pour spécifier le texte Unicode exact qu'une séquence de glyphes représente lorsque l'extraction du flux de contenu donnerait des résultats incorrects — les cas les plus courants sont les glyphes de ligature OpenType (U+FB00 ff, U+FB01 fi, U+FB02 fl) et les abréviations à expansions non évidentes. ActualText complète, plutôt que de remplacer, le contenu rendu ; il remplace ce que les technologies d'assistance et les extracteurs de texte lisent pour cet élément sans supprimer le rendu visuel. La fonction est disponible dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.31.1 2026-05-20

GetPDFUADiagnostics vérifie désormais les éléments de structure Formula en plus des éléments Figure lors du signalement de texte Alt manquant (FIGURE-NO-ALT:N). ISO 32000-1 §14.9.3 requiert des descriptions alternatives pour à la fois les figures graphiques et les formules mathématiques ; auparavant seuls les éléments Figure étaient scannés.
GetPDFUADiagnostics signale désormais PDF-VERSION-LOW lorsque la version PDF du document est inférieure à 1.7. PDF/UA-1 (ISO 14289-1) est défini par rapport à PDF 1.7 (ISO 32000-1:2008) ; les documents en PDF 1.5 ou 1.6 ne satisferaient pas les exigences de base de la spécification. Appelez SetPDFUAMode pour élever automatiquement la version à 1.7.

v3.31.0 2026-05-19

Les identifiants d'élément de structure et l'association des en-têtes de tableau sont désormais pris en charge. SetStructElemID assigne un identifiant de chaîne unique (/ID) à l'élément de structure actuellement ouvert ; les ID sont collectés dans un arbre de noms /IDTree sur la racine de l'arbre de structure lorsque le document est sauvegardé, permettant aux outils d'accessibilité et aux références croisées de localiser les éléments par ID (ISO 32000-1 §14.7.4). SetStructElemHeaders associe la cellule de tableau actuelle (TD ou TH) à une ou plusieurs cellules d'en-tête via une liste séparée par des virgules d'ID précédemment assignés, en écrivant le tableau /Headers dans le dictionnaire de propriétaire d'attribut Table (ISO 32000-1 §14.8.5.7.2). Ensemble, ces deux fonctions prennent en charge le balisage complexe de tableaux pour PDF/UA-1 (ISO 14289-1 §7.10) et WCAG 2.x SC 1.3.1. Les deux fonctions sont disponibles dans la bibliothèque Delphi, ActiveX et les interfaces DLL. AddTagAttribute gère également désormais correctement l'attribut /Headers avec des valeurs délimitées par des virgules écrites comme des tableaux de chaînes de texte PDF.

v3.30.1 2026-05-19

GetPDFUADiagnostics inclut désormais une vérification HEADING-LEVEL-SKIP:N qui détecte les sauts de niveau de titre dans l'ordre du document (par ex. un H1 immédiatement suivi d'un H3 sans H2 entre les deux). La vérification effectue un parcours pré-ordre de l'arbre complet des éléments de structure et compte chaque occurrence où le niveau de titre suivant dépasse le précédent de plus d'un. Les éléments H génériques sont traités comme H1. Revenir à un titre de niveau supérieur (H3 → H1) n'est pas compté comme un saut. WCAG 2.x Critère de Succès 1.3.1 et ISO 14289-1 §7.1 requièrent que les titres s'imbriquent sans écart.

v3.30.0 2026-05-19

Les attributs d'élément de structure sont désormais pris en charge pour les documents tagged-PDF et PDF/UA. Trois nouvelles fonctions d'API permettent d'attacher des attributs à l'élément de structure actuellement construit sur la pile de balises : AddTagAttribute (générique, n'importe quel propriétaire/nom/valeur), SetStructElemScope (wrapper de commodité qui définit l'attribut /Scope sous le propriétaire Table, pour les cellules d'en-tête TH — ISO 32000-1 §14.8.5.7.2) et SetStructElemBBox (wrapper de commodité qui définit l'attribut /BBox sous le propriétaire Layout, pour les figures et autres éléments positionnés visuellement — ISO 32000-1 §14.8.5.4). Lorsque le document est sauvegardé, les attributs sont écrits comme dictionnaires d'attributs /A dans chaque élément de structure ; plusieurs attributs du même propriétaire sont groupés en un seul dict, et les attributs de différents propriétaires sont écrits comme un tableau de dicts. Les trois fonctions sont disponibles dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.29.1 2026-05-19

GetPDFUADiagnostics inclut désormais deux vérifications supplémentaires : si des éléments de structure Figure dans le document sont dépourvus d'une valeur de texte Alt (signalé comme FIGURE-NO-ALT:N, selon ISO 14289-1 §7.5 et ISO 32000-1 §14.9.3), et si des éléments de structure sont encore ouverts parce que EndTag n'a pas été appelé (signalé comme STRUCT-UNCLOSED:N). La vérification de figure effectue un parcours récursif complet de l'arbre des éléments de structure, couvrant les éléments à toutes les profondeurs d'imbrication.

v3.29.0 2026-05-19

GetPDFUADiagnostics est une nouvelle API de diagnostic qui vérifie un document pour les problèmes potentiels de conformité PDF/UA-1 (ISO 14289-1) et retourne une liste de constats séparés par des sauts de ligne. Six vérifications sont effectuées : si MarkInfo/Marked est défini (tagged PDF), si le catalogue du document a une entrée /Lang, si ViewerPreferences/DisplayDocTitle est vrai, si les métadonnées XMP contiennent un identifiant pdfuaid:part, le nombre d'annotations non exemptées dépourvues d'une entrée Contents, et le nombre de fichiers intégrés dépourvus d'une entrée AFRelationship. Chaque constat est identifié par un code court (par ex. LANG-MISSING, ANNOT-NO-CONTENTS:3) suivi d'une description lisible par un humain. Retourne une chaîne vide lorsqu'aucun problème n'est trouvé. Disponible dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.28.5 2026-05-19

Amélioration d'accessibilité d'annotation PDF/UA-1 : lorsqu'une annotation FileAttachment n'a pas d'entrée Contents ni de champ /T, le nom de fichier de la spécification de fichier intégré de l'annotation (/FS /UF ou /F) est désormais utilisé comme description accessible de repli. Cela complète la chaîne de repli de Contents d'annotation : /T → URI de Link → nom de Stamp → nom de fichier de FileAttachment. Les lecteurs d'écran reçoivent le nom du fichier attaché plutôt que le silence, satisfaisant ISO 14289-1 §7.18.1 pour les types d'annotation les plus courants.

v3.28.4 2026-05-19

Amélioration d'accessibilité d'annotation PDF/UA-1 : lorsqu'une annotation Stamp n'a pas d'entrée Contents (ou une vide) ni de champ /T, le nom de type de tampon de l'entrée /Name de l'annotation est désormais utilisé comme description accessible de repli (par ex. "Approved", "Draft", "Confidential", "Final"). Cela étend la chaîne de repli de Contents d'annotation introduite en v3.28.3 pour couvrir les annotations de tampon, qui sont courantes dans les workflows impliquant des documents révisés ou approuvés et manquent fréquemment d'une valeur Contents explicite.

v3.28.3 2026-05-19

Amélioration d'accessibilité d'annotation PDF/UA-1 : lorsqu'une annotation Link n'a pas d'entrée Contents (ou une vide) ni de champ /T, l'URI de l'action URI de l'annotation est désormais utilisé comme description accessible de repli. Cela s'applique uniquement lors du traitement de SetPDFUAMode et uniquement aux annotations Link portant une action /URI. Les lecteurs d'écran reçoivent l'URL comme étiquette de dernier recours, satisfaisant ISO 14289-1 §7.18.1 dans le cas courant où les auteurs créent des hyperliens sans fournir de description lisible par un humain.

v3.28.2 2026-05-19

SetEmbeddedFileAFRelationship est une nouvelle API pour définir explicitement la valeur AFRelationship sur le dictionnaire de spécification de fichier d'un fichier intégré. Requise par ISO 14289-1 (PDF/UA-1) §7.11, elle permet aux appelants de spécifier la relation sémantique d'un fichier intégré au contenu du document en choisissant parmi les cinq valeurs valides : Source, Data, Alternative, Supplement ou Unspecified. Lorsque SetPDFUAMode est actif, tout fichier intégré sans clé AFRelationship se voit automatiquement assigner Unspecified ; utilisez cette fonction pour remplacer cette valeur par défaut avant la sauvegarde. Disponible dans la bibliothèque Delphi, ActiveX et les interfaces DLL.

v3.28.1 2026-05-19

Lorsque SetPDFUAMode est appelé sur un document dont les métadonnées XMP portent le titre générique par défaut de la bibliothèque plutôt qu'un titre spécifique au document, le titre est désormais automatiquement remplacé par la valeur de l'entrée Title du /Info du document (si présente). Cela garantit que le packet XMP pdfuaid:part-1 reflète le titre réel du document plutôt qu'un placeholder, satisfaisant les attentes du vérificateur PDF/UA-1.
Le parseur XMP (LoadFromString) lit désormais la valeur dc:title des métadonnées XMP existantes lorsqu'un document est chargé, de sorte qu'un aller-retour d'un PDF qui a déjà dc:title préserve correctement ce titre au lieu de revenir au placeholder par défaut.

v3.28.0 2026-05-19

BeginArtifactEx(ArtifactType, ArtifactSubtype) est une nouvelle API tagged-PDF qui étend BeginArtifact pour exprimer à la fois le /Type de l'artefact et le /Subtype Pagination en un seul appel. Lorsque les deux paramètres sont non vides, l'opérateur écrit est /Artifact << /Type /T /Subtype /S >> BMC, permettant des artefacts Pagination pleinement spécifiés tels que les en-têtes et pieds de page selon ISO 32000-1 §14.8.2.2.1. Si un seul paramètre est non vide, la forme à clé unique correspondante est utilisée. Les points d'entrée DLL DLBeginArtifactEx et DLBeginArtifactExA sont également exportés.

v3.27.2 2026-05-19

BeginArtifact distingue désormais correctement les types d'artefact des sous-types de pagination. Lorsque l'argument est Pagination, Layout ou Page (types d'artefact selon ISO 32000-1 §14.8.2.2.1 Table 330), l'opérateur de contenu marqué écrit /Type plutôt que /Subtype. D'autres valeurs telles que Header, Footer et Watermark continuent d'être écrites comme /Subtype. Cela corrige la sortie précédemment incorrecte qui écrivait /Subtype /Pagination lorsque l'appelant avait l'intention de marquer un artefact de pagination.

v3.27.1 2026-05-19

Lorsque le mode PDF/UA est actif et que le document contient des fichiers intégrés, chaque dictionnaire de spécification de fichier dépourvu d'une entrée AFRelationship en reçoit désormais une automatiquement au moment de la sauvegarde. La valeur écrite est /Unspecified, satisfaisant l'exigence ISO 14289-1 §7.11 que chaque fichier intégré porte une clé AFRelationship. Cela s'applique aux fichiers ajoutés via EmbedFile et aux fichiers intégrés déjà présents dans un document chargé.

v3.27.0 2026-05-19

AddRoleMap(CustomType, StandardType) est une nouvelle API tagged-PDF qui enregistre une correspondance entre un nom de type d'élément de structure personnalisé (non standard) et un type de structure PDF standard. Lors de la sauvegarde, les correspondances sont écrites dans le dictionnaire RoleMap de la racine de l'arbre de structure, satisfaisant l'exigence ISO 14289-1 §7.1 pour les documents qui utilisent des noms de balises spécifiques à l'application. Plusieurs correspondances peuvent être enregistrées ; les clés en doublon sont remplacées par le dernier appel. Les points d'entrée DLL DLAddRoleMap et DLAddRoleMapA sont également exportés.

v3.26.0 2026-05-19

BeginTagEx(TagType, AltText, ActualText, Lang) est une nouvelle API tagged-PDF qui étend BeginTag avec un attribut de langue naturelle explicite. Lorsque Lang est non vide, il est écrit dans l'attribut /Lang de l'élément de structure, permettant l'annotation de langue par élément requise par ISO 14289-1 §7.2 pour les documents multilingues. Passez une chaîne Lang vide pour vous comporter de façon identique à BeginTag. Les points d'entrée DLL DLBeginTagEx et DLBeginTagExA sont également exportés.

v3.25.1 2026-05-19

Les polices TrueType non sous-ensemblées chargées avec la page de codes Windows par défaut (WinAnsiEncoding) reçoivent désormais un flux CMap ToUnicode, permettant l'extraction Unicode fiable de texte et le copier/coller pour ces polices. Auparavant un flux ToUnicode n'était écrit que lorsqu'un remplacement explicite de page de codes ou un tableau Differences était présent ; le chemin courant d'encodage par défaut en manquait.
La même correction s'applique aux polices TrueType chargées avec une page de codes explicite non par défaut mais sans tableau Differences, et aux polices chargées via le format de police empaqueté.

v3.25.0 2026-05-19

Lorsque le mode PDF/UA est actif, les annotations non exemptées (tous les types sauf Widget, PrinterMark et TrapNet) dépourvues d'une entrée Contents non vide en reçoivent désormais une automatiquement au moment de la sauvegarde. La valeur /T (titre / auteur) de l'annotation est utilisée comme repli, satisfaisant ISO 14289-1 §7.18.1 pour les annotations qui portent un titre mais aucune description accessible explicite.

v3.24.0 2026-05-19

Lorsque le mode PDF/UA est actif, les champs de formulaire interactifs dépourvus d'une entrée TU (info-bulle / description alternative) en reçoivent désormais une automatiquement au moment de la sauvegarde. Le nom partiel du champ (entrée /T) est utilisé comme valeur de repli, garantissant que les lecteurs d'écran peuvent identifier chaque champ. Les boutons-poussoirs sont correctement exclus de cette exigence selon ISO 14289-1 §7.18.4.

v3.23.1 2026-05-19

GetInformation(200) retourne '1' lorsque le mode PDF/UA-1 est actif sur le document sélectionné, permettant aux appelants d'interroger le statut du mode de conformité à l'exécution.
GetInformation(201) retourne '1' pour PDF/A-1a, '2' pour PDF/A-1b, ou une chaîne vide lorsque le mode PDF/A est désactivé.
GetInformation(311) et GetInformation(312) retournent désormais correctement la chaîne d'exigence de version et le nom de la fonctionnalité du conflit de verrouillage de version le plus récent (précédemment annoncé dans l'entrée v3.20.3 mais pas encore implémenté).
GetInformation(313) retourne la chaîne de version PDF à laquelle la cible de sauvegarde est actuellement verrouillée, ou une chaîne vide pour les documents à versionnement libre.

v3.23.0 2026-05-19

SetMarkInfo(Marked) est désormais une API publique, permettant de définir l'indicateur MarkInfo.Marked indépendamment de la configuration PDF/UA-1 complète effectuée par SetPDFUAMode. Lorsque Marked vaut 1, MarkInfo.Suspects est également défini à false comme requis par ISO 14289-1 §7.18.6.
Lorsque le mode PDF/UA est actif, toutes les pages reçoivent automatiquement une entrée /Tabs /S au moment de la sauvegarde, satisfaisant l'exigence d'ordre de tabulation basé sur la structure de ISO 14289-1 §7.18.4.
Documentation de référence HTML ajoutée pour SetPDFUAMode, SetDocumentLanguage, SetMarkInfo, BeginTag, EndTag, BeginArtifact et EndArtifact, avec tables de syntaxe complètes et exemples d'usage.

v3.22.0 2026-05-19

BeginTag(TagType, AltText, ActualText) ouvre un élément de structure tagged-PDF dans le flux de contenu actuel, écrivant un opérateur BDC avec un MCID assigné automatiquement et enregistrant l'élément dans l'arbre de structure du document. TagType est n'importe quel type de structure standard PDF (P, H1, Figure, Table, etc.). AltText et ActualText sont des chaînes d'accessibilité optionnelles encodées comme chaînes de texte PDF (UTF-16BE).
EndTag ferme l'élément de structure le plus récemment ouvert, écrivant l'opérateur EMC correspondant dans le flux de contenu.
BeginArtifact(SubType) marque une région de contenu comme un artefact PDF (artefact de pagination, arrière-plan, etc.), écrivant un opérateur BMC. SubType est optionnel ; lorsque fourni, il est écrit comme /Artifact << /Subtype /SubType >>.
EndArtifact ferme la région d'artefact avec un opérateur EMC.
Au moment de la sauvegarde, lorsque des éléments de structure tagged ont été enregistrés, la bibliothèque construit automatiquement le StructTreeRoot complet, assigne les clés StructParents aux pages affectées et écrit l'arbre de nombres ParentTree, satisfaisant les exigences ISO 32000-1 §14.7 pour le tagged PDF.
Les polices standard Type 1 (Helvetica, Times, famille Courier, Symbol) et les polices Type 1 intégrées avec encodage WinAnsi reçoivent désormais un flux CMap ToUnicode, permettant l'extraction Unicode fiable de texte et le copier/coller pour ces types de polices.

v3.21.0 2026-05-19

SetPDFUAMode(Language) active le mode de conformité PDF/UA-1 (ISO 14289-1) : élève automatiquement le document à PDF 1.7, écrit MarkInfo.Marked et MarkInfo.Suspects, active DisplayDocTitle dans ViewerPreferences, définit Catalog.Lang lorsque Language est non vide, et écrit l'entrée d'espace de noms XMP pdfuaid:part = 1 requise par ISO 14289-1 Section 6.7.11.
SetDocumentLanguage(Language) écrit directement l'entrée Catalog /Lang, permettant de déclarer la langue du document indépendamment du mode PDF/UA.
MarkInfo.Suspects est désormais défini à false chaque fois que MarkInfo.Marked est défini à true, satisfaisant l'exigence de structure tagged-PDF de ISO 14289-1 (Section 7.18.6).
Encrypt force désormais l'indicateur de permission CanCopyAccess (copie de contenu pour l'accessibilité) lorsque le document est en mode PDF/UA, comme requis par ISO 14289-1 Section 7.17.
Les champs de formulaire Choice (liste déroulante) ne portent plus une valeur d'info-bulle codée en dur sans signification ; TU est laissé non défini afin que l'appelant puisse assigner une étiquette significative via l'API de propriétés de champ de formulaire.

v3.20.3 2026-05-19

Encrypt et AddSWFAnnotationFromFile retournent désormais 0 immédiatement avec LastErrorCode 602 lorsque la version de sauvegarde est verrouillée en dessous du minimum requis par la force de chiffrement ou le type d'annotation sélectionné, au lieu de procéder silencieusement et échouer uniquement au moment de la sauvegarde.
GetInformation(311) et GetInformation(312) reflètent désormais l'exigence de version conflictuelle au moment de l'écriture lorsqu'une version verrouillée bloque des fonctionnalités de niveau d'extension telles que AES-256 ou les annotations RichMedia.

v3.20.2 2026-05-19

AddU3DAnnotationFromFile élève désormais automatiquement la version du document à PDF 1.6 lorsqu'une annotation 3D est ajoutée à un document de version inférieure, conformément au comportement d'élévation automatique de version de tous les autres points d'entrée d'API PDF 1.6+.

v3.20.1 2026-05-17

Les cibles de sauvegarde PDF 1.2 sont désormais appliquées comme des contrats stricts PDF 1.2. Sauvegarder des objets PDF 1.3+ tels que les données TrimBox de page sous une cible PDF 1.2 échoue avant que la sortie ne soit écrite au lieu d'émettre un fichier à versions mixtes.
La conformité PDF 1.7 au niveau d'extension Adobe fait désormais partie du preflight de sauvegarde. AESV3, AES-256, RichMedia, Projection, dictionnaires géospatiaux et sous-filtres de signature ETSI sont vérifiés par rapport à l'ExtensionLevel requis.
Le chiffrement AES-256, les annotations RichMedia, les dictionnaires géospatiaux et les sous-filtres de signature ETSI déclarent désormais l'entrée Adobe Extensions correspondante lorsque PDFlib élève automatiquement un document à un contenu d'extension PDF 1.7.
Les sauvegardes incrémentielles utilisent désormais la même porte de conformité de version que les sauvegardes complètes.
Les DLL d'exécution PDFium optionnelles fournies ont été rafraîchies pour Win32 et Win64. GDI+ reste le moteur de rendu par défaut ; PDFium reste opt-in via SetPDFiumFileName et SelectRenderer(3).
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 207/207 chacune, et le GoogleTest C++Builder Win64x a passé 61 tests avec 2 tests dépendant d'échantillons existants ignorés.

v3.20.0 2026-05-17

Huit points d'entrée writer PDFlib supplémentaires passent désormais par Phase 3 EnsureMinVersion afin que la version du document soit automatiquement élevée au minimum requis par la fonctionnalité émise : SetDocumentMetadata (PDF 1.4 - flux XMP /Metadata) SetPDFAMode(1 ou 2) (PDF 1.4 - /MarkInfo + /OutputIntents) PageJavaScriptAction (PDF 1.5 - Page /AA + JavaScript) DocJavaScriptAction (PDF 1.4 - Catalog /AA + JavaScript) SetTabOrderMode (PDF 1.5 - Page /Tabs) NewOptionalContentGroup (PDF 1.5 - /Type /OCG) SetNeedAppearances (PDF 1.5 - AcroForm /NeedAppearances) NewFormField(ftSignature) (PDF 1.5 - AcroForm /SigFlags AppendOnly)
Combiné avec l'ensemble v3.15.0 (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout) et l'ensemble v3.17.0 (huit entrées JavaScript / fichier intégré / XFA / SWF), PDFlib élève désormais automatiquement FVersion sur vingt et un points d'entrée writer.
NewOptionalContentGroup élevait précédemment FVersion directement ; il passe désormais par EnsureMinVersion afin que LockSaveVersion soit respecté et que l'élévation soit enregistrée dans AutoBumpedFeatures.

v3.19.0 2026-05-17

La conformité de version PDF au moment de la sauvegarde et au moment du chargement reconnaît désormais également quatre fonctionnalités précédemment différées : Btn /Ff bit 15 NoToggleToOff (radio-button uniquement) -> PDF 1.4 DeviceN /Subtype /NChannel (raffinement d'espace de couleur) -> PDF 1.6 FontFile3 /Subtype /OpenType (type de programme de police) -> PDF 1.6 Sig /SubFilter ETSI.CAdES.detached ou ETSI.RFC3161 -> PDF 1.7
La règle NChannel correspond à la forme de tableau d'espace de couleur DeviceN [/DeviceN names alternateSpace tintTransform attributes] lorsque le dictionnaire d'attributs à l'index 4 porte /Subtype /NChannel.
La règle FontFile3 OpenType se déclenche uniquement lorsque le flux est atteint via une clé parent nommée 'FontFile3', de sorte que les flux non liés qui portent /Subtype /OpenType ne sont pas signalés.
La table PDFFeatureRules porte désormais 103 règles (99 + 4 nouvelles).

v3.18.6 2026-05-17

La conformité de version PDF au moment de la sauvegarde et au moment du chargement reconnaît désormais /AA (actions additionnelles) avec une prise en compte du type de conteneur : Catalog /AA (déclencheurs au niveau document) -> PDF 1.4 Annot /AA (déclencheurs d'annotation) -> PDF 1.4 Page /AA (déclencheurs de page) -> PDF 1.5
Le /AA de champ de formulaire (PDF 1.2) reste couvert par le contrat de sauvegarde PDF 1.3 existant ; aucune règle nécessaire.
La table PDFFeatureRules porte désormais 99 règles (96 + 3 nouvelles).

v3.18.5 2026-05-17

La conformité de version PDF au moment de la sauvegarde et au moment du chargement classe désormais correctement Page /Tabs comme une fonctionnalité PDF 1.5 ; elle était précédemment mal classée comme PDF 1.4. Le document de modifications de la spec PDF 1.4 (Adobe TN #5409) ne mentionne pas /Tabs, et PDF 1.5 Table 8.10 introduit "Tabs (Optional; PDF 1.5)".
Nouvelle règle : AcroForm /NeedAppearances est reconnu comme une fonctionnalité PDF 1.5 selon PDF 1.5 Table 218.
La table PDFFeatureRules porte désormais 96 règles (95 + 1 nouvelle).

v3.18.4 2026-05-13

PDFlibZLib utilise désormais toujours le backend d'objet zlib-ng statique fourni dans les builds normaux de la bibliothèque, supprimant le chemin de repli System.ZLib restant.
La couverture de régression zlib-ng inclut désormais des charges utiles de taille frontière, des données de scanline de type PNG, des flux multi-blocs stockés et des flux zlib connus à travers les runners de tests Delphi et C++Builder.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 194/194 chacune, et le GoogleTest C++Builder Win64x a passé 58 tests avec 2 tests dépendant d'échantillons existants ignorés.

v3.18.3 2026-05-12

Les démos Delphi et C++Builder qui génèrent une sortie PDF ou texte ouvrent désormais automatiquement le document généré après une sauvegarde réussie.
L'empaquetage de l'installeur garde désormais les artefacts de build en dehors des dossiers de démo et rend les échantillons C++Builder ainsi que les modules DLL et ActiveX/OCX en composants opt-in ; leurs fichiers correspondants sont installés uniquement lorsque le composant est sélectionné.

v3.18.2 2026-05-12

Les démos EditFormField Delphi et C++Builder effacent désormais /NeedAppearances avant de mettre à jour les valeurs des champs, afin que chaque champ texte édité obtienne un flux d'apparence normal rafraîchi dans le PDF sauvegardé.
Cela garde le flux /AP sauvegardé synchronisé avec la valeur /V stockée et évite les différences dépendantes de la visionneuse où le focus sur le champ révèle du texte qui manquait à l'apparence statique du champ.

v3.18.1 2026-05-10

La conformité de version PDF au moment de la sauvegarde et au moment du chargement reconnaît désormais également les drapeaux /Ff de champ de formulaire au niveau bit et le bit AcroForm /SigFlags AppendOnly : /Ff bit 21 (FileSelect, mask 1048576) -> PDF 1.4 /Ff bit 22 (MultiSelect, mask 2097152) -> PDF 1.4 /Ff bit 23 (DoNotSpellCheck, mask 4194304) -> PDF 1.4 /Ff bit 24 (DoNotScroll, mask 8388608) -> PDF 1.4 /Ff bit 25 (Comb, mask 16777216) -> PDF 1.5 /Ff bit 26 (RichText / RadiosInUnison, 33554432) -> PDF 1.5 /Ff bit 27 (CommitOnSelChange, mask 67108864) -> PDF 1.5 /SigFlags bit 2 (AppendOnly, mask 2) -> PDF 1.5
L'héritage /Parent n'est pas suivi : seuls les dictionnaires qui portent explicitement /Ff ou /SigFlags déclenchent les règles.
La table PDFFeatureRules porte désormais 95 règles (87 + 8 nouvelles au niveau bit).
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 191/191 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.18.0 2026-05-10

La conformité de version PDF au moment de la sauvegarde et au moment du chargement reconnaît désormais également neuf sous-clés et fonctionnalités au niveau bit supplémentaires : drapeaux d'annotation au niveau bit (/F mask) : Locked (128) -> PDF 1.4 ToggleNoView (256) -> PDF 1.5 LockedContents (512) -> PDF 1.7 sous-clés distinctives de catalogue et de page : /BoxColorInfo (page) -> PDF 1.4 /Permissions, /Legal, /PresSteps -> PDF 1.5 /VP (page geospatial viewport) -> PDF 1.6 /Collection (catalog portable collection) -> PDF 1.7
La table PDFFeatureRules porte désormais 87 règles (78 au niveau chapitre + 9 sous-clés / niveau bit).
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 189/189 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.17.0 2026-05-10

Huit points d'entrée writer PDFlib supplémentaires passent désormais par Phase 3 EnsureMinVersion afin que la version du document soit automatiquement élevée au minimum requis par la fonctionnalité émise : AddLinkToJavaScript, SetOpenActionJavaScript, AddGlobalJavaScript, FormFieldJavaScriptAction (PDF 1.3 - actions JavaScript) AddEmbeddedFile, AddFileAttachment (PDF 1.3 - pièces jointes) SetXFAFromString (PDF 1.5 - formulaires XFA) AddSWFAnnotationFromFile (PDF 1.7 - annotation RichMedia)
Combiné avec l'ensemble v3.15.0 (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout), PDFlib couvre désormais treize points d'entrée writer de version élevée de bout en bout.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 187/187 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.16.3 2026-05-10

Nouvelle API PDFlib : LockSaveVersion(Version) épingle le document à Version et empêche Phase 3 EnsureMinVersion côté writer d'élever automatiquement au-delà. UnlockSaveVersion supprime le verrou.
La porte au moment de la sauvegarde reste inchangée : les fonctionnalités émises par le writer au-dessus de la version verrouillée produisent toujours LastErrorCode 602 au moment de la sauvegarde, au lieu d'élever silencieusement l'en-tête.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 184/184 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.16.2 2026-05-10

Les PDF chargés exposent désormais une vue réservée aux contributeurs de la détection de fonctionnalités au moment du chargement via GetInformation(103) ("ContributorFeatures"). La liste ne contient que les fonctionnalités dont la version minimale requise est strictement supérieure à HeaderVersion (clé 100), elle répond donc directement à "pourquoi la version effective est-elle supérieure à l'en-tête du fichier ?".
GetInformation(101) ("DetectedFeatures") est inchangé et liste toujours toutes les fonctionnalités appariées indépendamment de leur contribution.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 181/181 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.16.1 2026-05-10

Couverture de test étendue de la détection côté chargeur avec six fixtures synthétiques supplémentaires : ExtGState de transparence intra-page (pas d'élévation de version), Catalog /MarkInfo (PDF 1.3 -> PDF 1.4), /OCProperties + contenu OCG (PDF 1.4 -> PDF 1.5), /Type /3DStream (PDF 1.5 -> PDF 1.6), une fixture de combinaison multi-fonctionnalités et une vérification de stabilité d'instantané.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 179/179 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.16.0 2026-05-10

Les documents PDF chargés passent désormais par une passe de détection de version pilotée par le contenu : chaque objet indirect est parcouru à travers la table fonctionnalité-vers-version-minimale utilisée par la porte au moment de la sauvegarde, et FVersion est élevé au-dessus de la valeur d'en-tête littérale %PDF-X.Y lorsque le contenu requiert réellement une version supérieure. Par exemple, une entrée de page /UserUnit élève la version effective à PDF 1.6 même lorsque l'en-tête du fichier dit PDF 1.4.
Nouvelles clés GetInformation : 100 retourne HeaderVersion (littéral %PDF-X.Y), 101 retourne DetectedFeatures (fonctionnalités détectées au chargement, délimitées par CRLF), 102 retourne AutoBumpedFeatures (fonctionnalités qui ont déclenché EnsureMinVersion côté writer, délimitées par CRLF).
La porte au moment de la sauvegarde n'est pas affectée : les documents dont la version effective a été élevée au chargement, puis explicitement rétrogradés avec SetInformation(0, ...), produisent toujours LastErrorCode 602 au moment de la sauvegarde.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 173/173 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.15.0 2026-05-10

Les points d'entrée writer qui produisent des fonctionnalités requérant une version PDF minimale particulière élèvent désormais automatiquement la version PDF du document. Appeler SetTransparency sur un document marqué comme PDF 1.3 promeut maintenant l'en-tête à PDF 1.4 au lieu de faire échouer la sauvegarde avec LastErrorCode 602.
Câblé la même élévation automatique dans SetPageUserUnit (>=1.6), Encrypt avec Strength 1/2/3/4 (>=1.4/1.6/1.7/1.7 respectivement), et les variantes à deux pages de SetPageLayout (>=1.5).
Changement de comportement par rapport à 3.14.x : les applications qui dépendaient précédemment de la porte v3.12.6 "la cible de sauvegarde rejette les fonctionnalités émises par le writer" réussissent désormais à la version élevée. Les PDF chargés qui contiennent déjà des fonctionnalités de version supérieure passent toujours par la porte existante au moment de la sauvegarde, de sorte que charger un PDF tagged et sélectionner PDF 1.3 échoue toujours avec LastErrorCode 602.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 170/170 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.14.3 2026-05-10

La conformité de version PDF au moment de la sauvegarde reconnaît désormais également les autres types de dictionnaire 3D PDF 1.6 (/Type /3DStream /3DRef /3DBackground /3DRenderMode /3DLightingScheme /3DCrossSection /3DNode) et les sous-types d'annotation PDF 1.7 Redact, RichMedia et Projection plus les dictionnaires compagnons /Type /Requirement et /ReqHandler.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 168/168 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.14.2 2026-05-10

La conformité de version PDF au moment de la sauvegarde reconnaît désormais également les fonctionnalités PDF 1.5 : formulaires /XFA, /AlternatePresentations, arbre de noms /Renditions, dictionnaires multimédia /Type /Rendition /MediaCriteria /MediaPermissions /MediaPlayers, et le sous-type d'annotation Screen.
Sauvegarder en PDF 1.4 rejette désormais les documents qui portent ces fonctionnalités avec LastErrorCode 602.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 166/166 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.14.1 2026-05-10

La conformité de version PDF au moment de la sauvegarde reconnaît désormais également les fonctionnalités PDF 1.4 : tagged-PDF /StructTreeRoot /MarkInfo et dictionnaires StructElem, entrées /Lang du document et /Tabs de page, dictionnaires /OutputIntents et /OutputIntent, signature de droits d'utilisation /UR3, et les sous-types d'annotation PDF 1.4 Polygon, PolyLine, Caret, Ink, Popup et Watermark.
Sauvegarder en PDF 1.3 rejette désormais les documents qui portent ces fonctionnalités avec LastErrorCode 602.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 165/165 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.14.0 2026-05-10

La conformité de version PDF au moment de la sauvegarde reconnaît désormais également les fonctionnalités PDF 1.3 telles que l'ombrage lisse, les objets fonction, les espaces de couleur ICCBased et DeviceN, les entrées de page /TrimBox /BleedBox /ArtBox, les CMaps /ToUnicode, les annotations de pièces jointes et /Sound et /Movie, les dicts /Type /Filespec et /Type /EmbeddedFile, les clés /Group /EF /Alternates /Mask, et les actions JavaScript.
Les appelants PDF 1.2 sauvegardent désormais sous le contrat PDF 1.3 : l'en-tête littéral %PDF-1.2 est préservé, mais la porte accepte les fonctionnalités PDF 1.3. Les fonctionnalités PDF 1.4 et ultérieures sont toujours rejetées avec LastErrorCode 602.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 162/162 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.13.0 2026-05-10

Refactoré la porte de conformité de version PDF qui rejette les fonctionnalités de version ultérieure au moment de la sauvegarde en un module dédié afin que l'ensemble de règles puisse croître sans agiter le cœur du document.
Aucun changement de comportement visible par l'utilisateur par rapport à v3.12.7 : les mêmes fonctionnalités hors version sont toujours rejetées avec LastErrorCode 602.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 155/155 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.12.7 2026-05-09

Couverture de tests automatisés étendue pour le workflow de rendu à accès direct PdfToImage dans les suites Delphi DUnitX et C++Builder GoogleTest.
Le runner de tests VCL GUI Delphi enregistre désormais les fixtures Syntax et XRef, correspondant à la couverture du runner console.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 147/147 chacune, et le GoogleTest C++Builder Win64x a passé 57/57.

v3.12.6 2026-05-09

Sauvegarder en PDF 1.3, 1.4, 1.5, 1.6 ou 1.7 applique désormais la version sélectionnée comme contrat de sortie de sauvegarde complète.
Les sauvegardes complètes suppriment les remplacements /Version du catalogue, suppriment les entrées d'extension et de métadonnées de catalogue non supportées pour les cibles inférieures, et suppriment les flux de métadonnées XMP PDF 1.4 lors de la sauvegarde en PDF 1.3.
SaveToFile, SaveToString et SaveToStream échouent désormais avec LastErrorCode 602 lorsque la version cible PDF sélectionnée est inférieure aux fonctionnalités encore présentes dans le document, telles que transparence, contenu optionnel, JPX, UserUnit, 3D ou fonctionnalités de filtre crypto AES.

v3.12.5 2026-05-09

Amélioré l'analyse des chaînes littérales PDF 1.7 afin que les séquences d'échappement inconnues ignorent l'antislash comme requis par le standard.
Les échappements octaux de chaîne littérale ne consomment désormais que des chiffres octaux et préservent un chiffre non octal suivant comme donnée de chaîne régulière.
Ajouté une couverture de régression pour les échappements de chaîne littérale inconnus et les séquences d'échappement mixtes octales/non octales.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 141/141 chacune.

v3.12.4 2026-05-09

Amélioré l'analyse lexicale PDF 1.7 afin que les objets de nom s'arrêtent maintenant correctement au délimiteur d'accolade droite.
Corrigé le chargement SmartAccess des entrées d'objets compressés de flux xref dont le numéro de flux d'objet est plus grand que la longueur en octets du PDF.
Ajouté une couverture de régression pour les délimiteurs de nom à accolade droite et les entrées de flux xref à objets compressés éparses.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 139/139 chacune.

v3.12.3 2026-05-08

Amélioré la compatibilité des documents chiffrés PDF 1.7 pour les fichiers du gestionnaire de sécurité standard qui utilisent des filtres crypto StrF, StmF, EFF, Identity, None ou nommés style StdCF.
Les flux de métadonnées respectent désormais EncryptMetadata=false pendant les workflows de déchiffrement, chiffrement et copie/sauvegarde au lieu d'être traités comme des flux ordinaires.
Les flux de fichier intégré portent désormais /Type /EmbeddedFile et utilisent le chemin de décision du filtre crypto de fichier intégré lorsque des documents chiffrés sont chargés ou sauvegardés.
Les flux de fichier intégré externes promeuvent désormais FDecodeParms en DecodeParms lorsque FFilter est promu en Filter, préservant les paramètres de décodage de flux.
Les nouveaux PDF chiffrés AES écrivent désormais les valeurs Length de filtre crypto comme longueurs en bits, correspondant au contrat de dictionnaire de filtre crypto PDF 1.7.
Les valeurs Prev/XRefStm de flux XRef et les grands décalages numériques conservent désormais une précision 64 bits à travers les chemins de parseur et SmartAccess.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 137/137 chacune.

v3.12.2 2026-05-08

Amélioré la compatibilité de décodage de flux PDF 1.7. Le décodage de flux générique honore désormais /DP comme alias de DecodeParms, résout les entrées de tableau de paramètres de décodage indirectes, et accepte les abréviations de filtre standard /AHx et /LZW.
La sortie PDF de grands fichiers écrit désormais les décalages xref, startxref, linéarisation et ByteRange de signature numérique via des chemins de formatage 64 bits au lieu de rétrécir ces valeurs à travers des helpers entiers 32 bits.
Les documents chargés traitent désormais une entrée /Version de catalogue comme la version PDF effective lorsqu'elle est plus récente que la version d'en-tête du fichier.
Les trailers de flux xref réécrits ne conservent plus les clés DecodeParms spécifiques aux flux lorsque PDFlibPas les sauvegarde comme dictionnaires de trailer classiques.
Validation : les suites DUnitX Delphi Win32 et Win64 ont passé 134/134 chacune.

v3.12.1 2026-05-06

Les PDF générés s'ouvrent désormais avec la première page dimensionnée à la hauteur disponible de la fenêtre de la visionneuse, de sorte que la première page entière soit visible de haut en bas au plus grand zoom qui tient dans la fenêtre. Configurez un OpenAction personnalisé (SetOpenActionDestination, SetOpenActionMenu, SetOpenActionJavaScript) sur le document pour remplacer ce comportement par défaut.

v3.12.0 2026-05-06

Les backends statiques Windows incluent désormais les objets SIMD NASM de libjpeg-turbo pour Win32 et Win64, ainsi que les objets de dispatch SIMD x86 zlib-ng pour l'ensemble zlib-ng Win64x.
Refonte des scripts de reconstruction zlib-ng afin que les builds Win64x bcc64x et MSVC de diagnostic compilent les fichiers source génériques, SSE2, SSSE3, SSE4.1/SSE4.2, PCLMULQDQ et AVX2 avec des drapeaux de fonctionnalité par fichier au lieu de dépendre d'un seul commutateur de compilateur global.
Ajouté des stubs CRT malloc/calloc/realloc/free alignés sur 32 octets pour les bibliothèques C statiques et corrigé TPDFJPEGImage.Compress pour libérer les tampons jpeg_mem_dest via le même chemin C free qui les a alloués.
Notes de validation publiques étendues pour mentionner la couverture automatisée stricte derrière cette version : builds de bibliothèque, aller-retours de compression, sortie /FlateDecode HelloWorld, rendu JPEG, workflows d'image, polices, formulaires, sécurité, signature, impression et workflows dérivés des démos C++Builder.

v3.11.0 2026-05-05

Basculé la compression et la décompression Flate Windows vers zlib-ng en mode compatible zlib. Win32, Delphi Win64 et C++Builder Win64x lient désormais des ensembles d'objets statiques zlib-ng à ABI appariée depuis Lib\thirdparty\Win32, Lib\thirdparty\Win64 et Lib\thirdparty\Win64x.
Le chemin Win64 ne passe plus par l'unité System.ZLib de Delphi, de sorte que la compression/décompression de flux PDF peut bénéficier du backend zlib-ng tout comme le build 32 bits.
Ajouté un petit objet pont zlib-ng pour les builds Win64 afin que le code Pascal garde des points d'entrée compatibles zlib stables tandis que Delphi et C++Builder consomment leurs propres ensembles d'objets compatibles avec leurs éditeurs de liens.
Mis à jour tous les projets de démo C++Builder pour définir PDFLIB_CPPBUILDER, correspondant au runner GoogleTest et empêchant les démos Win64x de lier les objets zlib-ng Delphi Win64.

v3.10.3 2026-05-01

Étendu la suite GoogleTest C++Builder pour couvrir chaque démo sous Demo\C++Builder. La disposition phase-1 à 7 fixtures est passée à 15 fixtures / 52 cas GoogleTest, tous réussis sur Win64x. Démos nouvellement couvertes : AddFormattedTitle, AddTextImage, AddTrueTypeSubsettedFont, AddWebLink, CanvasText, CaptureToNewSize, CopyPageRanges, CreateWithImage, CreateWithImageToStream, DoInTheStream, DrawWrappedText, EditFormField, EmbeddedFonts, ExtractAnnotAttach, ExtractEmbeddedFonts, ExtractImage, ImageToPdf, ImportEMF, MultiFunction (commutation de moteur de rendu), PageOperations, PdfDecrypt, PdfPermission, PrintPDF, TextMeasure, TextPaging.

v3.10.2 2026-05-01

Ajouté un runner GoogleTest C++Builder sous Tests\C++Builder qui exerce Lib\PDFlibrary.pas via les mêmes en-têtes HPP émis par {$JPHNE} utilisés par les démos C++Builder. La première phase reproduit sept scénarios Delphi de base (HelloWorld, DrawShapes, CreateTable, PdfEncrypt, ExtractText, PdfSigning, rendu PdfToImage) sous forme de 17 cas GoogleTest, tous réussis sur Win64x.
Étendu la suite DUnitX Delphi avec Tests.Print couvrant les démos PrintPDF et ShowPrinterBins (énumération d'imprimante par défaut, configuration d'imprimante personnalisée, options d'impression, tâche d'impression redirigée vers fichier) et un test de commutation de moteur de rendu dans Tests.Render exerçant la sélection de moteur GDI+ / PDFium / Cairo de la démo MultiFunction sur le même PDF source.

v3.10.1 2026-05-01

Ajout de 57 tailles de page nommées à SetPageSize afin que les mêmes noms canoniques de taille de page fonctionnent également ici : SIZE8X11, QUADA0, DOUBA0, B0PLUS, ENVB4/B5/C6/DL/MONARCH, ENV9/10/11, ANSIA/B/C/D/E, ARCHA/B/C/D/E1/E, SHIROKU, G1K, USBC/EUBC/ASBC, ID1/ID2/ID3, ONEINCH/TWOINCH/L2INCH/USVISA, P2R..P24R / S8R / P4D photo prints, plus the Chinese / Taiwanese octavo and sextodecimo sheet formats LARGE/STANDARD/CROWN/ROC 8K and the matching 16K halves.

v3.10.0 2026-04-30

Ajouté des versions C++Builder natives pour chaque exemple Delphi sous Demo. Les démos de création de PDF, manipulation de page, polices, images, sécurité, signature, rendu et impression peuvent désormais être construites et exécutées depuis C++Builder sans aucun wrapper côté Delphi.
Chaque nouvelle démo se trouve dans Demo\C++Builder\<Name>\ en tant que projet console qui consomme directement Lib\PDFlibrary.pas et est livrée avec les fichiers d'entrée nécessaires à l'exécution.
Ajouté un bref Readme.txt en anglais à chaque dossier de démo Delphi décrivant ce que la démo montre, l'API qu'elle cible et comment l'exécuter ; une vue d'ensemble HTML à Demo\Delphi\index.html lie à toutes ces démos regroupées par sujet.
Reproduit le même Readme.txt pour chaque démo C++Builder avec une section Run réécrite pour le workflow console (arguments argv au lieu de Open/SaveDialogs) ; un Demo\C++Builder\index.html correspondant liste chaque démo C++Builder avec les mêmes groupes de sujets.
Corrigé une fuite mémoire dans la démo ImportEMF (l'instance TPDFlib était créée mais jamais libérée).

v3.9.14 2026-04-30

Corrigé la démo de copie de plage de pages afin qu'elle copie réellement les pages au lieu de toujours signaler un échec.
Rangé les démos de texte enveloppé et de pagination HTML afin que chacune se concentre sur sa propre API et s'exécute à partir d'un seul bouton.
Renommé deux projets de démo (EmbeddedFonts et PdfPermission) afin que les exécutables compilés correspondent aux noms de dossier au lieu des anciens noms de prototype.

v3.9.13 2026-04-30

Corrigé un bogue de position de flux dans le reader de tampon interne : les lectures de mot de deux octets avançaient le curseur de lecture de quatre octets au lieu de deux. Dans les tampons plus longs que deux octets, les lectures suivantes atterrissaient au mauvais décalage et retournaient silencieusement des données incorrectes. L'effet était le plus visible lors de l'analyse de structures de données binaires qui entrelacent les lectures d'octet et de mot.
Introduit une suite de tests DUnitX automatisée (runners console et VCL GUI) couvrant les unités utilitaires — tampon, AES, ZLib, Unicode et hachage de résumé — et les workflows au niveau bibliothèque incluant la création de document, la sauvegarde sur fichier et sur flux, les allers-retours de chargement et le chiffrement AES-128/AES-256.

v3.9.12 2026-04-30

Le rendu d'image GDI+ utilise désormais par défaut l'interpolation bicubique lisse et de haute qualité lors de la mise à l'échelle d'images matricielles vers une résolution écran ou d'export. Le précédent défaut était le plus proche voisin, ce qui produisait des artefacts d'escalier visibles sur les petites images (logos, vignettes) agrandies pour l'aperçu à l'écran ou l'export haute DPI. Les appelants qui préfèrent le mode plus net du plus proche voisin peuvent restaurer l'ancien comportement via SetGDIPlusOptions.

v3.9.11 2026-04-30

Corrigé le rendu Cairo des images PDF qui utilisent la transparence par clé de couleur (un tableau de plage de couleurs /Mask dans le dictionnaire d'image). Précédemment, lorsqu'une page contenait une image avec cette forme de transparence, le moteur de rendu Cairo omettait entièrement l'image au lieu de la composer avec l'arrière-plan de la page. La correction dérive un canal alpha par pixel à partir des plages de clé de couleur déclarées et rend le résultat comme une image transparente, produisant une sortie visuellement cohérente avec le moteur de rendu GDI+.

v3.9.10 2026-04-30

Corrigé une régression de rendu Cairo où tout contenu de page suivant une séquence d'image découpée était incorrectement confiné au rectangle de découpage de l'image. Les pages PDF qui sauvegardent l'état graphique, appliquent un chemin de découpage, peignent une image, puis restaurent l'état — une technique de mise en page courante pour les images encadrées ou bordées — rendaient tous les textes, formes et graphiques suivants à l'intérieur de la région découpée uniquement. La sauvegarde et restauration d'état Cairo correspondent désormais correctement aux opérateurs q/Q PDF, de sorte que la région de découpage est écartée après que l'image est dessinée.

v3.9.9 2026-04-29

Ajouté un moteur de rendu PDF basé sur Cairo comme troisième option de rendu aux côtés de GDI+ et PDFium. Appelez SelectRenderer(2) avant le rendu pour l'activer ; le moteur requiert cairo.dll du dossier DLL\Cairo fourni. Le rendu Cairo prend en charge les mêmes modes de sortie que GDI+ : export de fichier bitmap et flux (BMP, JPEG, PNG, GIF, TIFF, G4 TIFF), rendu vers contexte de périphérique et sortie d'imprimante directe.
La démo MultiFunction View/Print expose désormais un sélecteur de moteur de rendu à trois voies afin que les utilisateurs puissent comparer la sortie GDI+, PDFium et Cairo côte à côte sur le même document sans aucun changement de code.

v3.9.8 2026-04-29

Supprimé deux diagnostics de compilateur fallacieux dans le shim C-runtime Win32 qui apparaissaient sur RAD Studio 13.1 et ultérieur. Un avertissement de dépréciation (W1000) était levé parce qu'un garde de capacité de version de compilateur n'était pas propagé aux compilateurs plus récents que Delphi 2009, les amenant à compiler contre une API de gestionnaire de mémoire dépréciée. Un indice de variable non utilisée (H2164) était levé pour une variable de compatibilité interne uniquement nécessaire pour les builds Delphi 7 ; elle est désormais limitée au bloc conditionnel de cette version. Les deux problèmes étaient uniquement diagnostiques sans impact d'exécution.

v3.9.7 2026-04-29

Ajouté le rendu de page basé sur PDFium optionnel sur Windows, incluant le rendu de flux BMP, le rendu de contexte de périphérique, le rendu mémoire et la sortie d'imprimante.
Mis à jour la démo Delphi MultiFunction View/Print avec un sélecteur de moteur de rendu afin que les utilisateurs puissent basculer entre le moteur GDI+ existant et PDFium.

v3.9.6 2026-04-29

Ajouté des scripts Inno Setup séparés pour le paquet PDFlibPas complet et le paquet d'essai, avec des exclusions axées sur la version pour les métadonnées de contrôle de source, les sorties de build, les caches IDE, les fichiers d'agent locaux et les arbres source tiers fournis qui ne font pas partie du paquet livré.
L'installeur d'essai construit et empaquette désormais les bibliothèques binaires d'essai pour RAD Studio 11.3, 12.3 et 13.1, plus les démos Delphi d'essai, avant que l'exécutable de configuration ne soit généré.

v3.9.5 2026-04-29

Corrigé les builds de bibliothèque Win32 sous RAD Studio 9.0 / Delphi XE2. Le script de build transmettait un drapeau de répertoire de sortie DCU qui n'existe qu'à partir de Delphi 2010 ; le compilateur de XE2 interprétait le drapeau différemment, produisant un chemin de sortie incorrect et une erreur fatale avant que tout fichier source ne soit traité. Le script sélectionne désormais automatiquement le drapeau approprié selon la version du compilateur cible.
Corrigé un garde de version de compilateur connexe dans le code source de la bibliothèque qui appelait une fonction d'exécution qualifiée par nom introduite dans XE4 sous une condition XE2+. Les builds ciblant XE2 et XE3 résolvent désormais l'import de compatibilité correct à la place.

v3.9.4 2026-04-29

Corrigé la configuration d'imprimante pour les imprimantes réseau et partagées par serveur en appliquant les paramètres de bac à papier, média, recto-verso, qualité et autres paramètres d'impression via le handle DEVMODE de l'imprimante au lieu du handle de contexte de périphérique d'imprimante.

v3.9.3 2026-04-29

Rafraîchi le backend AES fourni vers les sources AES 2018 de Brian Gladman sur Win32 et Win64. Des scripts de build reproductibles permettent désormais de reconstruire les objets AES statiques depuis la source à tout moment. Un défaut ABI dans les bindings Pascal a été découvert et corrigé dans le processus : les fonctions de chiffrement et déchiffrement AES-CBC manquaient leur déclaration de convention d'appel C, de sorte que les builds Win32 transmettaient silencieusement les arguments dans le mauvais ordre de registres, produisant potentiellement une sortie chiffrée incorrecte. Les builds Win64 n'étaient pas affectés car la plateforme impose une convention d'appel uniforme.
Durci les scripts de reconstruction tiers afin que les scripts zlib, JPEG et stub CRT basés sur MSVC puissent être lancés depuis la racine du dépôt ainsi que depuis le répertoire thirdparty ; précédemment ils requéraient que le répertoire de travail soit défini sur le dossier thirdparty.

v3.9.2 2026-04-29

Mis à niveau le backend JPEG 2000 de l'ancien OpenJPEG 1.5 vers OpenJPEG 2.5.4 sur Win32 et Win64. Les deux plateformes utilisent désormais le linkage d'objet statique, de sorte que l'encodage et le décodage JPEG 2000 fonctionnent sans DLL d'exécution supplémentaire. Le codec moderne apporte la gestion d'en-tête JP2/J2K actuelle, une API de flux pilotée par callback et des correctifs accumulés de bogues et de sécurité du projet en amont. L'API publique TJpeg2000Bitmap est inchangée.

v3.9.1 2026-04-29

Corrigé le rendu de page JPEG et l'export d'image après la mise à niveau libjpeg-turbo, restaurant la conversion JPG PdfToImage et la sortie TPDFJPEGImage.SaveToStream sur Win32 et Win64.
Corrigé les bindings ABI libjpeg-turbo Win32 afin que les callbacks, l'alignement de structure, les champs booléens et les destinations JPEG soutenues par la mémoire correspondent à libjpeg-turbo 3.1.90.
Corrigé la décompression de flux FlateDecode Win32 avec le backend zlib 1.3.2 fourni, restaurant le chargement de flux xref PDF pour des fichiers tels que le document échantillon PdfToImage.

v3.9.0 2026-04-29

Mis à niveau le backend JPEG 2000 fourni de l'ancien OpenJPEG 1.5 vers OpenJPEG 2.5.4. Le chargement et l'enregistrement JPEG 2000 utilisent désormais le codec moderne, l'API de flux pilotée par callback et la gestion d'en-tête JP2/J2K actuelle tout en préservant l'API publique TJpeg2000Bitmap.
La sortie JPEG 2000 sélectionne désormais automatiquement un nombre de résolutions OpenJPEG valide pour les petites images, et le backend statique Win32 ne dépend plus des exports d'aide MSVCRT manquants.

v3.8.1 2026-04-29

Éliminé les 16 avertissements cosmétiques de l'éditeur de liens W1028 "Bad global symbol definition" sur Win32 et Win64. Les renommages au niveau source suppriment les doublons redondants côté Pascal (jpeg_std_error et les stubs allocateur jmemnobs se résolvent maintenant uniquement depuis la couche obj) ; les trois symboles obj bcc32 / vc64 restants (jpeg_natural_order, jpeg_aritab, jpeg_nbits_table) qui doivent rester résolus par lien contre les données côté Pascal sont désormais dépouillés de leurs noms de symboles COFF via une passe de post-traitement ObjConv durant thirdparty\build-jpeg-vc64.bat. Aucun changement d'API publique ; sortie de l'éditeur de liens propre pour les builds Delphi Win32 et Win64.

v3.8.0 2026-04-29

Codec JPEG Win64 mis à niveau de libjpeg style IJG vers libjpeg-turbo 3.1.90, achève la migration JPEG démarrée en v3.7.0 (Win32). Les deux chemins Win32 et Win64 partagent désormais le même codec JPEG moderne, avec les mêmes boucles internes optimisées SIMD et plus de 30 correctifs CVE / fuzz accumulés en amont. L'API publique PDFlibPas est inchangée.

v3.7.0 2026-04-28

Codec JPEG Win32 mis à niveau de IJG libjpeg-6b vers libjpeg-turbo 3.1.90. Encodage/décodage JPEG significativement plus rapide grâce aux boucles internes optimisées SIMD, plus les 30+ correctifs CVE / fuzz accumulés en amont de libjpeg-turbo. L'API publique PDFlibPas (classe TPDFJPEGImage, fonctions DumpJPEG) est inchangée ; les chemins de code PDF/JPEG existants s'exécutent plus rapidement sans changements de source requis.

v3.6.0 2026-04-28

zlib Win32 mis à niveau de 1.2.x vers 1.3.2. Inclut les 25+ correctifs CVE / fuzz standard accumulés en amont depuis 1.2.8, plus les nouveaux points d'entrée inflateBack9 / inflateTree9 utilisés par les flux à fenêtre 64 bits. L'API publique PDFlibPas (DeflateStr / InflateStr / InflateStrParms) est inchangée.
Le chemin zlib Win64 est inchangé dans cette version — il continue d'utiliser l'unité System.ZLib fournie avec Delphi.
Activé le shim CRT au moment du linkage Win64 PDFlibCLibs.pas (introduit en v3.5.0) pour le chemin zlib Win32, fournissant les symboles memcpy / memset / malloc / free auxquels les nouveaux fichiers obj zlib 1.3.2 font référence.

v3.5.0 2026-04-28

Internalisé une infrastructure de build fraîche pour les bibliothèques C d'image / compression fournies : zlib 1.3.2, libjpeg-turbo 3.1.90, libtiff 4.7.1. Les scripts de build pour Embarcadero bcc32 (Win32) et MSVC cl.exe (Win64) vivent dans Lib/thirdparty/ aux côtés des arbres source, de sorte que quiconque a RAD Studio + VS2022 peut reconstruire les fichiers obj statiques depuis une source propre.
Ajouté une infrastructure de build pour OpenJPEG 2.5.4. L'arbre source OpenJPEG lui-même est récupéré indépendamment par l'utilisateur (git clone uclouvain/openjpeg dans Lib/thirdparty/OpenJPEG/) afin qu'il puisse être mis à niveau sans toucher à la configuration de build de PDFlibPas.
Ajout de Lib/PDFlibCLibs.pas, une couche CRT de liaison Win64 utilisée par le backend Win64. Elle comble l'écart entre les fichiers obj C compilés avec MSVC et les éditeurs de liens Win64 de Delphi (dcc64 / Win64x ld.lld / BCB ilink64), qui n'intègrent pas automatiquement msvcrt.dll.

v3.4.0 2026-04-28

Durci la génération de clé de chiffrement, du vecteur d'initialisation AES et du bloc de permission Perms contre les sources de nombres aléatoires prévisibles. Les PDF chiffrés produits sur des systèmes démarrés près du même temps d'horloge murale ne sont plus trivialement corrélables ; les documents AES-256 conservent désormais leur pleine force de clé.
Durci l'analyse de dictionnaire d'image contre les PDF mal formés ou hostiles qui déclarent des valeurs Width, Height, BitsPerComponent ou des comptages de composants DeviceN déraisonnables. Les valeurs hors plage sont serrées avant toute arithmétique de tampon de pixels, empêchant les plantages lors de l'ouverture de tels fichiers.
Durci la traversal de références croisées et de l'arbre de pages contre les documents dont les chaînes xref /Prev ou les liens de page /Parent forment un cycle ou sont excessivement profondes. Le reader rejette désormais proprement les structures mal formées au lieu de récurser jusqu'à épuiser sa pile.

v3.3.1 2026-04-27

Rationalisé les scripts de build Windows par composant. Les dossiers DLL/, OCX/ et Dylib/ ne portent plus de variantes build12-* / build13-* séparées : chaque plateforme a désormais un seul script build-Win32 / build-Win64 qui s'épingle au dernier RAD Studio et accepte un argument optionnel "debug".
Ajouté des commentaires inline de justification autour des correctifs de rendu PDFlibRenderer.pas qui étaient déjà présents dans la ligne de base Git initiale. Les commentaires documentent pourquoi SetPen met à l'échelle les largeurs de trait par la transformation de canevas active, et pourquoi les opérateurs CharProc d0/d1 de police Type 3 doivent consommer leurs opérandes. Aucun changement de comportement d'exécution.

v3.3.0 2026-04-26

Corrigé le rendu de trait transformé dans PDFlibRenderer.pas. SetPen applique désormais l'échelle de transformation de canevas actuelle aux largeurs de ligne PDF avant d'appeler Picasso, empêchant les traits surdimensionnés ou sous-dimensionnés sur les chemins dont les coordonnées ont déjà été transformées. Cela corrige les contours de glyphe Type 3 qui pouvaient se rendre comme des blocs épais et irréguliers.
Corrigé la gestion CharProc d0/d1 de police Type 3 dans le parseur de flux de contenu. d0 consomme désormais ses deux opérandes de largeur, et d1 consomme ses six opérandes de largeur/boîte englobante avant que les commandes de dessin ultérieures ne s'exécutent, empêchant les opérandes périmées de corrompre la géométrie de glyphe ou de chemin.