Conversão de PDF carregado para raster PDF/A-4
HPDFArchivalConversion cria um novo documento PDF/A-4 a partir do conteúdo visível das páginas de um documento THotPDF carregado, usando renderização nativa estrita e um perfil ICC sRGB fornecido
Cada página de saída contém uma imagem raster RGB comprimida sem perdas no DPI pedido, com as dimensões visíveis originais, o crop, a rotação e o UserUnit refletidos na geometria da página de saída
Use o perfil de preservação de texto e vetores separado quando os tipos de letra embedded originais, operadores de texto, paths vetoriais, imagens, camadas OCR e aparências visíveis de anotações ou widgets têm de sobreviver; o perfil raster não preserva essas estruturas
Pontos 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;
Carregue primeiro a origem e mantenha vivo qualquer stream de entrada pertencente ao chamador até o documento de origem ser destruído
Use o ponto de entrada por ficheiro para publicação normal de arquivo: ele analisa o destino existente para detetar aliasing com a origem antes de criar um ficheiro temporário exclusivo no diretório de destino, valida a conversão completa, faz flush do ficheiro e substitui o destino com MoveFileEx usando MOVEFILE_REPLACE_EXISTING e MOVEFILE_WRITE_THROUGH
Falhas de conversão, renderização, validação, cancelamento e publicação preservam o ficheiro de destino existente e removem a saída temporária
O ponto de entrada por stream exige um destino vazio que suporte seek, posicionado em zero, e rejeita aliases conhecidos da entrada através de IsLoadedSourceStreamAlias; só publica os bytes depois de toda a saída preparada passar a validação nativa
Uma falha de escrita no destino dispara um reset de melhor esforço para um stream vazio, mas um dispositivo arbitrário ou um stream personalizado pode rejeitar esse reset e reter uma escrita parcial; use o ponto de entrada por ficheiro quando a publicação tiver de ser atómica
Opções e limites de recursos
| Opção | Predefinição | Significado |
|---|---|---|
DPI | 150 | Resolução física pedida, intervalo aceite de 36 a 1200 |
MaxPages | 1000 | Número máximo de páginas de origem carregadas |
MaxPixelsPerPage | 40 000 000 | Máximo de píxeis por página e máximo de píxeis de cada imagem de origem |
MaxTotalPixels | 500 000 000 | Máximo acumulado de píxeis raster de saída |
MaxRasterBytes | 256 MiB | Alocação máxima de raster por página ou por imagem de origem, verificada de forma conservadora a quatro bytes por píxel |
MaxOutputBytes | 256 MiB | Tamanho máximo do PDF preparado, imposto antes da alocação e escrita no stream |
MaxDecodedStreamBytes | 64 MiB | Limita cada cadeia de filtros, o preflight combinado do conteúdo de cada página, cada callback nativo de leitura de stream, cada stream de imagem de origem codificada e o validador nativo de saída |
MaxTotalDecodedBytes | 256 MiB | Limita o trabalho adicional nativo de descodificação com filtros ao longo da conversão, o preflight combinado de conteúdo entre páginas e os callbacks nativos acumulados de leitura de stream entre páginas |
MaxInputObjects | 200 000 | Número máximo de objetos indiretos já carregados |
CancellationToken | nil | Token emprestado, verificado antes do trabalho, durante a renderização e a descodificação nativas e antes da publicação |
Checkpoint | nil | Callback síncrono emprestado, invocado com um sender nulo nos checkpoints de conversão e de recursos nativos; não reentre no documento de origem |
Os limites de descodificação contabilizam trabalho do descodificador e podem cobrar de novo o mesmo stream filtrado durante o preflight, a compilação da display list e a renderização; aumentar um orçamento é uma decisão explícita do chamador
O preflight de píxeis cobre tanto a resolução física pedida como o DPI inteiro do renderizador nativo após o escalonamento de UserUnit; unidades muito pequenas podem exigir píxeis raster adicionais, e dimensões de página fracionárias podem introduzir reamostragem subpixel quando a imagem é remapeada para a página física
Os limites de conversão aplicam-se depois do carregamento da origem; configure os limites de recursos do próprio carregador quando aceitar entrada não fidedigna
O grafo de objetos da origem é mantido, enquanto caches de leitura e estatísticas de descodificação podem ser preenchidas; as definições de renderização, o token de cancelamento, o backend e os orçamentos de descodificação são restaurados em caso de sucesso ou de falha
Dê ao conversor acesso exclusivo ao documento de origem enquanto ele aplicar temporariamente estas definições
Renderização e cor
Todas as páginas têm de renderizar sem diagnóstico nativo de fallback, sem diagnóstico de descarte e sem falha de recurso em falta; conteúdo não suportado rejeita a conversão em vez de publicar uma página incompleta
O argumento ICC tem de descrever sRGB com uma representação matriz/TRC reconhecida, os primários padrão adaptados a D50 e a função de transferência IEC sRGB; perfis RGB sem relação, perfis CMYK, perfis malformados e perfis baseados em LUT são rejeitados
A saída declara um OutputIntent sRGB e metadados XMP PDF/A-4; um fluxo de prova ou de ICC de saída personalizado já configurado na origem é rejeitado, porque as definições do descodificador de imagens não podem ser reinterpretadas de forma segura como sRGB
A build FPC exige a sua ponte nativa de codecs com o LittleCMS disponível e rejeita a conversão quando falta esse backend de gestão de cor
Os streams de imagem JPEG e JPX, incluindo imagens inline codificadas, têm as dimensões reais do codestream inspecionadas antes da descodificação nativa de píxeis e têm de coincidir com o dicionário de imagem do PDF
O JPEG aceita cabeçalhos baseline, sequential estendido e progressivos de 8 bits com limites; o JPX aceita cabeçalhos J2K SIZ com limites e caixas JP2 de comprimento ordinário com no máximo quatro componentes e precisão de componente de no máximo 16 bits
Os codecs codificados têm um orçamento de trabalho conservador adicional de 64 bytes por píxel de origem, e os metadados de tile do JPX ficam limitados tanto por MaxInputObjects como por 1024 bytes por tile dentro de MaxRasterBytes; o orçamento raster predefinido de 256 MiB permite, portanto, no máximo 4 194 304 píxeis de origem codificados, e quem chama pode aumentá-lo explicitamente para imagens maiores
A conversão JBIG2 é rejeitada porque as alocações internas de regiões e símbolos não podem ser limitadas pela API de cabeçalhos disponível; codecs de imagem não terminais, caixas JP2 de comprimento estendido, wrappers não suportados e streams de codec com DecodeParms também são rejeitados
Os parâmetros de fax CCITT têm de manter as dimensões positivas de imagem declaradas; overrides de DecodeParms.Columns e Rows diferentes do dicionário, incluindo um Rows=0 desconhecido, são rejeitados antes da descodificação nativa
Estas verificações limitam os perfis conhecidos de cabeçalhos e alocações aceite por este conversor e não prometem uma sandbox completa de memória de processo para todos os descodificadores nativos
Perda de informação e de qualidade
- Conteúdo vetorial, tipos de letra, transparência e espaços de cor da origem tornam-se píxeis RGB de página; um DPI maior melhora o detalhe visual mas aumenta o uso de memória e o tamanho do ficheiro
- O texto de saída não é pesquisável nem selecionável, e não é sintetizada qualquer camada de texto ou saída OCR
- Anotações, aparências de anotações, campos de formulário, aparências de widgets e aparências visíveis de assinaturas são omitidos em vez de incorporados no raster da página
- Assinaturas digitais, ficheiros embebidos, scripts, ações, marcadores, camadas como controlos interativos, etiquetas estruturais e a identidade original do documento não são mantidos
- O resultado não preserva a editabilidade vetorial, a validade original das assinaturas, a acessibilidade PDF/UA nem a semântica do documento de origem
THPDFArchivalConversionReport fornece o estado de sucesso e de cancelamento, contagens de páginas de origem e renderizadas, píxeis raster, bytes de saída, contagens de anotações, formulários e anexos removidos, um diagnóstico de falha e as conclusões da validação nativa
FailureKind distingue afkNone, afkConversion, afkBudget e afkCancelled; falhas tipadas de orçamento do conversor também fornecem BudgetMetric, BudgetObserved e BudgetLimit
Uma exceção num checkpoint para a conversão e é comunicada pelo resultado nativo de falha; wrappers que exijam a categoria original da exceção do callback têm de a reter antes de o conversor a apanhar
A operação JSON e C ABI archive.pdfa4.raster exige aceitação explícita da perda de informação, preserva o handle da origem, entrega o PDF validado e o relatório de perdas e aplica limites conservadores de orçamento de job
Verificação de conformidade
O conversor recarrega a saída preparada e exige ValidatePDFA4 com o perfil base PDF/A-4 antes da publicação; o validador nativo cobre o conjunto limitado de regras documentado e não é prova de todos os requisitos da ISO 19005-4
A aceitação independente pode usar veraPDF com --flavour 4; o fixture de regressão contendo texto não embebido, transparência, uma imagem RGB, um link, um widget de assinatura e um anexo passou no veraPDF 1.30.2 sem regras ou verificações falhadas
Execute Tests/Delphi/Run-HotPDFArchivalTests.bat para a suite de regressão não-GUI dedicada