Conversión de PDF cargado a raster PDF/A-4
HPDFArchivalConversion crea un nuevo documento PDF/A-4 a partir del contenido visible de las páginas de un documento THotPDF cargado, usando render nativo estricto y un perfil ICC sRGB suministrado
Cada página de salida contiene una imagen raster RGB comprimida sin pérdida al DPI solicitado, con sus dimensiones visibles originales, su recorte, su rotación y su UserUnit reflejados en la geometría de la página de salida
Use el perfil de preservación de texto y vectores separado cuando las fuentes embebidas originales, los operadores de texto, los paths vectoriales, las imágenes, las capas de OCR y las apariencias visibles de annotations o widgets deban sobrevivir; el perfil raster no preserva esas estructuras
Puntos de entrada
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;Carguen primero el origen y mantengan vivo cualquier stream de entrada propiedad de quien llama hasta que el documento de origen se destruya
Usen el punto de entrada de archivo para la publicación de archivo ordinaria: sondea un destino existente en busca de alias del origen antes de crear un archivo temporal exclusivo en el directorio de destino, valida la conversión completa, vacía el archivo y reemplaza el destino con MoveFileEx usando MOVEFILE_REPLACE_EXISTING y MOVEFILE_WRITE_THROUGH
Los fallos de conversión, render, validación, cancelación y publicación conservan un archivo de destino existente y eliminan la salida temporal
El punto de entrada de stream exige un destino vacío y posicionable en la posición cero, y rechaza los alias conocidos de la entrada mediante IsLoadedSourceStreamAlias; publica los bytes solo después de que la salida completa en staging pase la validación nativa
Un fallo de escritura en el destino dispara un reset de mejor esfuerzo hacia un stream vacío, pero un dispositivo arbitrario o un stream personalizado puede rechazar ese reset y conservar una escritura parcial; usen el punto de entrada de archivo cuando la publicación del archivo deba ser atómica
Opciones y límites de recursos
| Opción | Predeterminado | Significado |
|---|---|---|
DPI | 150 | Resolución física solicitada, rango aceptado de 36 a 1200 |
MaxPages | 1000 | Número máximo de páginas de origen cargadas |
MaxPixelsPerPage | 40,000,000 | Máximo de píxeles por página y máximo de píxeles de cada imagen de origen |
MaxTotalPixels | 500,000,000 | Máximo acumulado de píxeles raster de salida |
MaxRasterBytes | 256 MiB | Asignación raster máxima de página o de imagen de origen, verificada de forma conservadora a cuatro bytes por píxel |
MaxOutputBytes | 256 MiB | Tamaño máximo del PDF en staging, aplicado antes de la asignación y la escritura del stream |
MaxDecodedStreamBytes | 64 MiB | Acota cada cadena de filtros, el preflight combinado de contenido de cada página, los callbacks individuales de lectura nativa de stream, los streams individuales de imágenes de origen codificadas y el validador nativo de salida |
MaxTotalDecodedBytes | 256 MiB | Acota el trabajo adicional de decodificadores nativos con filtros a lo largo de la conversión, el preflight combinado de contenido entre páginas y los callbacks acumulados de lectura nativa de stream entre páginas |
MaxInputObjects | 200,000 | Número máximo de objetos indirectos ya cargados |
CancellationToken | nil | Token prestado que se verifica antes del trabajo, durante el render y la decodificación nativos, y antes de la publicación |
Checkpoint | nil | Callback sincrónico prestado que se invoca con un sender nil en los checkpoints de conversión y de recursos nativos; no reentren al documento de origen |
Los límites de decodificación cuentan el trabajo del decodificador y pueden cobrar el mismo stream filtrado otra vez durante el preflight, la compilación de display lists y el render; aumentar un presupuesto es una decisión explícita de quien llama
El preflight de píxeles cubre tanto la resolución física solicitada como el DPI entero del renderer nativo después del escalado por UserUnit; las unidades muy pequeñas pueden requerir píxeles raster adicionales, y las dimensiones fraccionarias de página pueden introducir resampling subpíxel cuando la imagen se mapea de vuelta a la página física
Los límites de conversión se aplican después de cargar el origen; configuren los límites de recursos propios del loader al aceptar entrada no confiable
El grafo de objetos del origen se conserva, mientras que las cachés de lectura y las estadísticas de decodificación pueden quedar pobladas; la configuración de render, el token de cancelación, el backend y los ajustes de presupuesto de decodificación se restauran tanto en éxito como en fallo
Denle al convertidor acceso exclusivo a su documento de origen mientras aplica temporalmente esta configuración
Render y color
Cada página debe renderizar sin un diagnóstico nativo de fallback, sin un diagnóstico descartado y sin un fallo de recurso faltante; el contenido no soportado rechaza la conversión en lugar de publicar una página incompleta
El argumento ICC debe describir sRGB con una representación matrix/TRC reconocida, los primarios estándar adaptados a D50 y la función de transferencia sRGB de IEC; se rechazan los perfiles RGB sin relación, los perfiles CMYK, los perfiles malformados y los perfiles basados en LUT
La salida declara un OutputIntent sRGB y metadatos XMP de PDF/A-4; un workflow ICC de proof o de salida ya configurado en el origen se rechaza porque su configuración del decodificador de imágenes no puede reinterpretarse de forma segura como sRGB
La compilación FPC requiere su puente nativo de codecs con LittleCMS disponible y rechaza la conversión cuando falta ese backend de gestión de color
Los streams de imágenes JPEG y JPX, incluidas las imágenes inline codificadas, tienen sus dimensiones reales de codestream inspeccionadas antes de la decodificación nativa de píxeles y deben coincidir con el diccionario de imágenes del PDF
JPEG acepta encabezados acotados baseline de 8 bits, secuenciales extendidos y progresivos; JPX acepta encabezados J2K SIZ acotados y cajas JP2 de longitud ordinaria con a lo sumo cuatro componentes y precisión de componente de a lo sumo 16 bits
Los codecs codificados tienen un presupuesto adicional de trabajo conservador de 64 bytes por píxel de origen, y los metadatos de tiles JPX están limitados tanto por MaxInputObjects como por 1024 bytes por tile dentro de MaxRasterBytes; el presupuesto raster predeterminado de 256 MiB admite por lo tanto a lo sumo 4,194,304 píxeles de origen codificados, y quienes llaman pueden aumentarlo explícitamente para imágenes más grandes
La conversión JBIG2 se rechaza porque sus asignaciones internas de regiones y símbolos no pueden acotarse desde la API de encabezados disponible; también se rechazan los codecs de imágenes nonterminal, las cajas JP2 de longitud extendida, los wrappers no soportados y los streams de codecs envueltos que llevan DecodeParms
Los parámetros de fax CCITT deben conservar las dimensiones de imagen positivas declaradas; los overrides de DecodeParms.Columns y Rows que difieran del diccionario, incluido un Rows=0 desconocido, se rechazan antes de la decodificación nativa
Estas comprobaciones acotan los perfiles conocidos de encabezados y asignaciones que este convertidor acepta, y no prometen un sandbox completo de memoria de proceso para cada decodificador nativo
Pérdida de información y de calidad
- El contenido vectorial, las tipografías, la transparencia y los espacios de color del origen se convierten en píxeles RGB de página; un DPI mayor mejora el detalle visual pero aumenta el uso de memoria y el tamaño del archivo
- El texto de salida no es buscable ni seleccionable, y no se sintetiza ninguna capa de texto ni salida OCR
- Las anotaciones, las apariencias de anotaciones, los campos de formulario, las apariencias de widgets y las apariencias visibles de firmas se omiten en lugar de incorporarse al raster de la página
- Las firmas digitales, los archivos embebidos, los scripts, las actions, los marcadores, las capas como controles interactivos, las etiquetas estructurales y la identidad original del documento no se conservan
- El resultado no preserva la editabilidad vectorial, la validez original de las firmas, la accesibilidad PDF/UA ni la semántica del documento de origen
THPDFArchivalConversionReport proporciona el estado de éxito y de cancelación, los conteos de páginas de origen y renderizadas, los píxeles raster, los bytes de salida, los conteos de anotaciones/formularios/adjuntos eliminados, un diagnóstico de fallo y los findings de la validación nativa
FailureKind distingue afkNone, afkConversion, afkBudget y afkCancelled; los fallos tipados de presupuesto del convertidor también entregan BudgetMetric, BudgetObserved y BudgetLimit
Una excepción de checkpoint detiene la conversión y se reporta a través del resultado nativo de fallo; los wrappers que necesiten la categoría original de la excepción del callback deben retenerla antes de que el convertidor la capture
La operación JSON y C ABI archive.pdfa4.raster exige aceptación explícita de la pérdida de información, preserva el handle del origen, entrega el PDF validado y el reporte de pérdida, y aplica topes conservadores de presupuesto por job
Verificación de conformidad
El convertidor recarga su salida en staging y exige ValidatePDFA4 con el perfil base de PDF/A-4 antes de publicar; el validador nativo cubre su conjunto acotado de reglas documentado y no es una prueba de cada requisito de ISO 19005-4
La aceptación independiente puede usar veraPDF con --flavour 4; el fixture de regresión que contiene texto sin embeber, transparencia, una imagen RGB, un link, un widget de firma y un adjunto pasó veraPDF 1.30.2 sin reglas ni comprobaciones fallidas
Ejecuten Tests/Delphi/Run-HotPDFArchivalTests.bat para la suite de regresión no GUI enfocada