Compatibilidade de salvamento por versão PDF

A versão 3.23.0 trata a versão de salvamento PDF selecionada como um contrato estrito para salvamentos completos. Quando um aplicativo chama SetInformation(0, "1.2"), "1.3", "1.4", "1.5", "1.6" ou "1.7", SaveToFile, SaveToString e SaveToStream gravam uma saída que corresponde ao destino selecionado ou falham antes de escrever qualquer saída

Os salvamentos completos removem substituições Catalog /Version para que um documento carregado não possa elevar silenciosamente a versão efetiva acima do cabeçalho selecionado. Destinos de versão inferior também removem entradas Catalog /Extensions sem suporte, e destinos PDF 1.3 omitem Catalog /Metadata e fluxos XMP Metadata, preservando o dicionário de informações do documento

A pré-verificação de salvamento rejeita recursos conhecidos de versões posteriores em vez de produzir um arquivo com versões misturadas. Os limites verificados incluem caixas de página PDF 1.3, fluxos de arquivo incorporados, ações JavaScript, espaços de cor ICCBased e DeviceN e ToUnicode CMaps; transparência PDF 1.4, estruturas Tagged PDF, output intents e chaves de anotação; object streams PDF 1.5, conteúdo opcional, XFA, page tabs, flags append-only de campos de assinatura e flags avançadas de campos de formulário; PDF 1.6 UserUnit, programas de fonte OpenType, dicionários 3D, espaços de cor NChannel e dados de viewport; e PDF 1.7 RichMedia, Projection, Redaction, anotações avançadas e subfiltros de assinatura ETSI; o mesmo conjunto de regras também cobre opacidade annotation /CA, JBIG2Decode, fluxos Metadata, a árvore de nomes EmbeddedFiles no nível do documento, JPXDecode, xref streams, Crypt filters, AESV2 crypt filters e PDF 1.7 Requirements

Os requisitos de nível de extensão Adobe do PDF 1.7 são verificados separadamente do cabeçalho PDF 1.7. AESV3, AES-256, RichMedia, Projection, dicionários geoespaciais e subfiltros de assinatura ETSI devem ter uma declaração Catalog /Extensions /ADBE /ExtensionLevel suficiente antes que o destino de salvamento selecionado seja aceito. Os pontos de entrada writer que emitem esses recursos de nível de extensão adicionam automaticamente a declaração de extensão correspondente quando o destino selecionado pode ser elevado para PDF 1.7

Desde v3.67.0, a detecção de recursos de conteúdo no lado do carregador é preguiçosa. Um documento carregado não é verificado imediatamente; a detecção é executada na primeira vez em que a versão efetiva ou os diagnósticos de recursos de carregamento são consumidos por GetInformation(0/101/103), GetPDFUADiagnostics, SaveToFile, SaveToString, SaveToStream ou caminhos append-save relacionados. Fluxos de trabalho somente leitura que nunca consultam esses diagnósticos e nunca salvam podem pular a verificação por completo

Desde v3.67.1, a verificação de detecção faz parsing superficial de objetos stream. Ela inspeciona dicionários de objeto e a classificação do stream enquanto ignora corpos de stream grandes, mantendo equivalente a detecção de filtros, subtipos, espaços de cor e chaves vinculadas à versão enquanto grandes fluxos de imagem deixam de dominar a verificação. Leituras normais de objeto e todos os caminhos de salvamento ainda leem o corpo completo do stream quando a saída exige

Desde v3.67.2, escolhas explícitas de versão de salvamento mantêm prioridade sobre a detecção preguiçosa. Em um documento carregado, SetInformation(0, ...) e LockSaveVersion executam o snapshot de detecção pendente antes de aplicar a versão solicitada, portanto um salvamento ou consulta diagnóstica posterior não pode elevar o destino selecionado sem o chamador. Documentos recém-criados não são armados para detecção no lado do carregador, preservando o comportamento anterior de controle de versão apenas pelo writer

Chamadores de TPDFlib recebem LastErrorCode 602 quando a versão de destino selecionada é inferior a um recurso ainda presente no documento. Escolha uma versão de destino mais recente ou remova o recurso incompatível antes de salvar