Conversion d'un PDF chargé en document raster PDF/A-4

HPDFArchivalConversion crée un nouveau document PDF/A-4 à partir du contenu visible des pages d'un document THotPDF chargé, via un rendu natif strict et un profil ICC sRGB fourni

Chaque page en sortie contient une image raster RGB compressée sans perte à la résolution demandée, ses dimensions visibles d'origine, son crop, sa rotation et son UserUnit étant reflétés dans la géométrie de la page en sortie

Utilisez le profil préservant texte et vecteurs séparé quand les polices embarquées d'origine, les opérateurs de texte, les tracés vectoriels, les images, les couches OCR et les apparences visibles d'annotations ou de widgets doivent survivre ; le profil raster ne préserve pas ces structures

Points d'entrée

function HPDFConvertLoadedToPDFA4Raster(Source: THotPDF;
  Destination: TStream; const SRGBProfile: TBytes;
  const Options: THPDFArchivalConversionOptions;
  out Report: THPDFArchivalConversionReport): Boolean;

function HPDFConvertLoadedToPDFA4RasterFile(Source: THotPDF;
  const TargetFileName: string; const SRGBProfile: TBytes;
  const Options: THPDFArchivalConversionOptions;
  out Report: THPDFArchivalConversionReport): Boolean;

Chargez d'abord la source et gardez en vie tout flux d'entrée appartenant à l'appelant jusqu'à la destruction du document source

Utilisez le point d'entrée fichier pour une publication d'archivage ordinaire : il sonde la cible existante pour détecter un alias de la source avant de créer un fichier temporaire exclusif dans le répertoire cible, valide la conversion complète, vide le fichier, puis remplace la cible avec MoveFileEx et les options MOVEFILE_REPLACE_EXISTING et MOVEFILE_WRITE_THROUGH

Un échec de conversion, de rendu, de validation, d'annulation ou de publication conserve le fichier cible existant et supprime la sortie temporaire

Le point d'entrée flux exige une destination vide, accessible par seek et positionnée à zéro, et rejette les alias connus de l'entrée via IsLoadedSourceStreamAlias ; il ne publie les octets qu'après validation native de l'intégralité de la sortie préparée

Un échec d'écriture vers la destination déclenche une remise à zéro en best-effort du flux, mais un périphérique ou un flux personnalisé arbitraire peut refuser cette remise à zéro et conserver une écriture partielle ; utilisez le point d'entrée fichier lorsque la publication doit être atomique

Options et limites de ressources

Option	Défaut	Signification
`DPI`	150	Résolution physique demandée, plage acceptée de 36 à 1200
`MaxPages`	1000	Nombre maximal de pages source chargées
`MaxPixelsPerPage`	40,000,000	Nombre maximal de pixels de page et de pixels d'une image source individuelle
`MaxTotalPixels`	500,000,000	Nombre maximal cumulé de pixels raster en sortie
`MaxRasterBytes`	256 Mio	Allocation raster maximale par page ou par image source, contrôlée de manière conservatrice à quatre octets par pixel
`MaxOutputBytes`	256 Mio	Taille maximale du PDF préparé, appliquée avant l'allocation et l'écriture du flux
`MaxDecodedStreamBytes`	64 Mio	Borne chaque chaîne de filtres, le preflight combiné du contenu de chaque page, les callbacks individuels de lecture de flux natifs, les flux d'images sources encodés individuels et le validateur natif de sortie
`MaxTotalDecodedBytes`	256 Mio	Borne le travail supplémentaire de décodage filtré natif sur toute la conversion, le preflight combiné du contenu entre pages et les callbacks cumulés de lecture de flux natifs entre pages
`MaxInputObjects`	200,000	Nombre maximal d'objets indirects déjà chargés
`CancellationToken`	`nil`	Jeton emprunté contrôlé avant le travail, pendant le rendu et le décodage natifs, et avant la publication
`Checkpoint`	`nil`	Callback synchrone emprunté, invoqué avec un sender nil aux points de contrôle de conversion et de ressources natives ; ne réentrez pas dans le document source

Les limites de décodage comptent le travail des décodeurs et peuvent facturer à nouveau le même flux filtré durant le preflight, la compilation de display list et le rendu ; augmenter un budget est une décision explicite de l'appelant

Le preflight des pixels couvre à la fois la résolution physique demandée et la résolution entière du moteur de rendu natif après la mise à l'échelle UserUnit ; des unités très petites peuvent exiger des pixels raster supplémentaires, et des dimensions de page fractionnaires peuvent introduire un rééchantillonnage subpixel lorsque l'image est remappée sur la page physique

Les limites de conversion s'appliquent après le chargement de la source ; configurez les propres limites de ressources du chargeur pour accepter une entrée non fiable

Le graphe d'objets de la source est conservé, tandis que les caches de lecture et les statistiques de décodage peuvent être remplis ; les réglages de rendu, le jeton d'annulation, le backend et les budgets de décodage sont restaurés en cas de succès comme d'échec

Accordez au convertisseur un accès exclusif à son document source pendant qu'il applique temporairement ces réglages

Rendu et couleur

Chaque page doit être rendue sans diagnostic natif de fallback, sans diagnostic abandonné ni échec de ressource manquante ; un contenu non pris en charge rejette la conversion au lieu de publier une page incomplète

L'argument ICC doit décrire sRGB avec une représentation matrice/TRC reconnue, les primaires standard adaptées D50 et la fonction de transfert sRGB IEC ; les profils RGB sans rapport, les profils CMYK, les profils malformés et les profils à base de LUT sont rejetés

La sortie déclare un OutputIntent sRGB et des métadonnées XMP PDF/A-4 ; un workflow ICC d'épreuvage ou de sortie personnalisé déjà configuré sur la source est rejeté, car ses réglages de décodeur d'images ne peuvent pas être réinterprétés de manière sûre comme sRGB

La build FPC exige son pont de codecs natif avec LittleCMS disponible et rejette la conversion si ce backend de gestion des couleurs est absent

Les flux d'images JPEG et JPX, y compris les images inline encodées, voient leurs dimensions réelles de codestream inspectées avant le décodage natif des pixels et doivent correspondre au dictionnaire d'image PDF

JPEG accepte des en-têtes baseline, extended sequential et progressifs bornés sur 8 bits ; JPX accepte des en-têtes J2K SIZ bornés et des boxes JP2 de longueur ordinaire avec au plus quatre composants et une précision de composant d'au plus 16 bits

Les codecs encodés disposent d'un budget de travail conservateur supplémentaire de 64 octets par pixel source, et les métadonnées de tuiles JPX sont limitées à la fois par MaxInputObjects et par 1024 octets par tuile dans MaxRasterBytes ; le budget raster par défaut de 256 Mio n'autorise donc au plus que 4,194,304 pixels source encodés, et les appelants peuvent l'augmenter explicitement pour des images plus grandes

La conversion JBIG2 est rejetée car ses allocations internes de régions et de symboles ne peuvent pas être bornées depuis l'API d'en-tête disponible ; les codecs d'images non terminaux, les boxes JP2 de longueur étendue, les wrappers non pris en charge et les flux de codecs enveloppés portant DecodeParms sont également rejetés

Les paramètres fax CCITT doivent conserver les dimensions d'image positives déclarées ; les overrides DecodeParms.Columns et Rows différents du dictionnaire, y compris un Rows=0 inconnu, sont rejetés avant le décodage natif

Ces contrôles bornent les profils d'en-tête et d'allocation connus acceptés par ce convertisseur et ne promettent pas un sandbox mémoire de processus complet pour chaque décodeur natif

Perte d'information et de qualité

Le contenu vectoriel, les polices, la transparence et les espaces colorimétriques sources deviennent des pixels de page RGB ; une résolution plus élevée améliore le détail visuel mais augmente l'usage mémoire et la taille du fichier
Le texte en sortie n'est ni recherchable ni sélectionnable, et aucune couche de texte ni sortie OCR n'est synthétisée
Les annotations, apparences d'annotations, champs de formulaire, apparences de widgets et apparences de signatures visibles sont omises plutôt que figées dans le raster de la page
Les signatures numériques, fichiers embarqués, scripts, actions, signets, calques en tant que contrôles interactifs, tags structurels et identité du document d'origine ne sont pas conservés
Le résultat ne préserve ni l'éditabilité vectorielle, ni la validité des signatures d'origine, ni l'accessibilité PDF/UA, ni la sémantique du document source

THPDFArchivalConversionReport fournit l'état de succès et d'annulation, les nombres de pages source et rendues, les pixels raster, les octets en sortie, les nombres d'annotations/formulaires/pièces jointes supprimés, un diagnostic d'échec et les constatations de la validation native

FailureKind distingue afkNone, afkConversion, afkBudget et afkCancelled ; les échecs de budget typés du convertisseur fournissent aussi BudgetMetric, BudgetObserved et BudgetLimit

Une exception de checkpoint arrête la conversion et est rapportée via le résultat d'échec natif ; les wrappers qui exigent la catégorie d'exception d'origine du callback doivent la conserver avant que le convertisseur ne la capture

L'opération archive.pdfa4.raster JSON et ABI C exige l'acceptation explicite de la perte d'information, préserve le handle source, livre le PDF validé et le rapport de perte, et applique des plafonds conservateurs de budget de job

Vérification de conformité

Le convertisseur recharge sa sortie préparée et exige ValidatePDFA4 avec le profil PDF/A-4 de base avant publication ; le validateur natif couvre son ensemble documenté de règles bornées et n'est pas une preuve de toutes les exigences ISO 19005-4

Une acceptation indépendante peut utiliser veraPDF avec --flavour 4 ; le fixture de régression contenant du texte non embarqué, de la transparence, une image RGB, un lien, un widget de signature et une pièce jointe est passé sous veraPDF 1.30.2 sans aucune règle ni vérification en échec

Exécutez Tests/Delphi/Run-HotPDFArchivalTests.bat pour la suite de régression non GUI ciblée