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 solicitado, com as dimensões visíveis originais, o recorte, a rotação e o UserUnit refletidos na geometria da página de saída
Use o profile de preservação de texto e vetor separado quando fontes embutidas originais, operators de texto, paths vetoriais, imagens, camadas de OCR e appearances visíveis de anotações ou widgets precisam sobreviver; o profile 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 a origem primeiro e mantenha vivo qualquer stream de entrada de propriedade do chamador até que o documento de origem seja destruído
Use o ponto de entrada por arquivo para a publicação de arquivamento comum: ele sonda um destino existente em busca de apelidos da origem antes de criar um arquivo temporário exclusivo no diretório de destino, valida a conversão completa, faz o flush do arquivo 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 um arquivo de destino existente e removem a saída temporária
O ponto de entrada por stream exige um destino vazio e com seek na posição zero, e rejeita apelidos conhecidos da entrada por meio de IsLoadedSourceStreamAlias; ele só publica os bytes depois que toda a saída preparada passa pela validação nativa
Uma falha de gravação no destino dispara uma redefinição de melhor esforço para um stream vazio, mas um device arbitrário ou um stream personalizado pode rejeitar essa redefinição e manter uma gravação parcial; use o ponto de entrada por arquivo quando a publicação do arquivo precisar ser atômica
Opções e limites de recursos
| Opção | Padrão | Significado |
|---|---|---|
DPI | 150 | Resolução física solicitada, faixa aceita de 36 a 1200 |
MaxPages | 1000 | Número máximo de páginas de origem carregadas |
MaxPixelsPerPage | 40.000.000 | Máximo de pixels por página e máximo de pixels de uma única imagem de origem |
MaxTotalPixels | 500.000.000 | Máximo acumulado de pixels raster de saída |
MaxRasterBytes | 256 MiB | Alocação raster máxima por página ou imagem de origem, verificada de forma conservadora a quatro bytes por pixel |
MaxOutputBytes | 256 MiB | Tamanho máximo do PDF preparado, aplicado antes da alocação e da gravação no stream |
MaxDecodedStreamBytes | 64 MiB | Limita cada cadeia de filtros, o preflight combinado de conteúdo de cada página, callbacks individuais de leitura de stream nativos, streams individuais de imagens de origem codificadas e o validador nativo de saída |
MaxTotalDecodedBytes | 256 MiB | Limita o trabalho adicional de decodificadores filtrados nativos ao longo da conversão, o preflight combinado de conteúdo entre páginas e os callbacks acumulados de leitura de stream nativa entre páginas |
MaxInputObjects | 200.000 | Contagem máxima de objetos indiretos já carregados |
CancellationToken | nil | Token emprestado, verificado antes do trabalho, durante a renderização e a decodificação nativas e antes da publicação |
Checkpoint | nil | Callback síncrono emprestado, invocado com sender nil nos checkpoints de conversão e de recursos nativos; não reentre no documento de origem |
Os limites de decodificação contam trabalho do decodificador e podem cobrar o mesmo stream filtrado novamente 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 pixels cobre tanto a resolução física solicitada quanto o DPI inteiro do renderer nativo após o escalonamento do UserUnit; unidades muito pequenas podem exigir pixels raster adicionais, e dimensões fracionárias de página podem introduzir reamostragem subpixel quando a imagem é mapeada de volta para a página física
Os limites de conversão se aplicam depois do carregamento da origem; configure os limites de recursos do próprio loader ao aceitar entrada não confiável
O grafo de objetos da origem é preservado, enquanto caches de leitura e estatísticas de decodificação podem ser populados; as configurações de renderização, token de cancelamento, backend e orçamento de decodificação são restauradas no sucesso e na falha
Dê ao conversor acesso exclusivo ao documento de origem enquanto ele aplica essas configurações temporariamente
Renderização e cor
Toda página precisa renderizar sem diagnóstico de fallback nativo, diagnóstico descartado ou falha de recurso ausente; conteúdo não suportado rejeita a conversão em vez de publicar uma página incompleta
O argumento ICC precisa descrever sRGB com uma representação matrix/TRC reconhecida, os primários padrão adaptados a D50 e a função de transferência sRGB da IEC; perfis RGB não relacionados, perfis CMYK, perfis malformados e perfis baseados em LUT são rejeitados
A saída declara um OutputIntent sRGB e metadados XMP de PDF/A-4; um fluxo de trabalho customizado de proof ou de ICC de saída já configurado na origem é rejeitado, porque as configurações do decodificador de imagens dele não podem ser reinterpretadas com segurança como sRGB
O build FPC exige a ponte nativa de codecs com o LittleCMS disponível e rejeita a conversão quando esse backend de gerenciamento de cor está ausente
Streams de imagem JPEG e JPX, incluindo imagens inline codificadas, têm as dimensões reais do codestream inspecionadas antes da decodificação nativa de pixels e precisam coincidir com o dicionário de imagem do PDF
JPEG aceita cabeçalhos limitados baseline de 8 bits, sequenciais estendidos e progressivos; JPX aceita cabeçalhos J2K SIZ limitados e boxes JP2 de comprimento comum com no máximo quatro componentes e precisão de componente de no máximo 16 bits
Codecs codificados têm um orçamento de trabalho conservador adicional de 64 bytes por pixel de origem, e os metadados de tile JPX são limitados por MaxInputObjects e por 1024 bytes por tile dentro de MaxRasterBytes; o orçamento raster padrão de 256 MiB portanto permite no máximo 4.194.304 pixels de origem codificados, e você pode aumentá-lo explicitamente para imagens maiores
A conversão JBIG2 é rejeitada porque as alocações internas de região e de símbolo não podem ser limitadas pela API de cabeçalho disponível; codecs de imagem nonterminal, boxes 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 precisam manter as dimensões positivas de imagem declaradas; overrides de DecodeParms.Columns e Rows que diferem do dicionário, incluindo Rows=0 desconhecido, são rejeitados antes da decodificação nativa
Essas verificações limitam os perfis conhecidos de cabeçalho e alocação aceitos por este conversor e não prometem um sandbox completo de memória de processo para cada decodificador nativo
Perda de informação e qualidade
- Conteúdo vetorial, fontes, transparência e espaços de cor da origem viram pixels RGB de página; DPI maior melhora o detalhe visual, mas aumenta o uso de memória e o tamanho do arquivo
- O texto de saída não é pesquisável nem selecionável, e nenhuma camada de texto ou saída de OCR é sintetizada
- Anotações, aparências de anotações, campos de formulário, aparências de widgets e aparências visíveis de assinatura são omitidos em vez de serem incorporados ao raster da página
- Assinaturas digitais, arquivos embutidos, scripts, actions, bookmarks, layers como controles interativos, tags estruturais e a identidade original do documento não são retidos
- O resultado não preserva editabilidade vetorial, validade original das assinaturas, acessibilidade PDF/UA nem a semântica do documento de origem
O THPDFArchivalConversionReport fornece estado de sucesso e cancelamento, contagens de páginas de origem e renderizadas, pixels raster, bytes de saída, contagens de anotações/formulários/anexos removidos, um diagnóstico de falha e os achados da validação nativa
O FailureKind distingue afkNone, afkConversion, afkBudget e afkCancelled; falhas tipadas de orçamento do conversor também fornecem BudgetMetric, BudgetObserved e BudgetLimit
Uma exceção em checkpoint interrompe a conversão e é reportada pelo resultado nativo de falha; wrappers que precisam da categoria original da exceção do callback devem retê-la antes de o conversor capturá-la
A operação archive.pdfa4.raster em JSON e C ABI 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 tetos conservadores de orçamento por job
Verificação de conformidade
O conversor recarrega a saída preparada e exige ValidatePDFA4 com o perfil base de PDF/A-4 antes da publicação; o validador nativo cobre seu conjunto documentado e limitado de regras e não é uma prova de todos os requisitos da ISO 19005-4
A aceitação independente pode usar o veraPDF com --flavour 4; o fixture de regressão contendo texto não embutido, 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 reprovadas
Execute o Tests/Delphi/Run-HotPDFArchivalTests.bat para a suíte de regressão não GUI focada