PDF/A, PDF/X e PDF/UA são três normas distintas que resolvem problemas diferentes: arquivo a longo prazo, intercâmbio de impressão e acessibilidade. Não se trata de três caixas de seleção num único formulário de conformidade, e o erro mais comum é tratá-los como se o fossem. Um ficheiro pode ser um PDF/A impecável e inútil para uma tipografia; um ficheiro master de impressão perfeito pode ser ilegível para um leitor de ecrã. Pior ainda, as três normas impõem restrições à estrutura interna do ficheiro, e não ao seu aspeto visual. Um documento que se abre perfeitamente em todos os seus visualizadores pode falhar a validação na primeira tentativa, e normalmente falha.
O HotPDF, a biblioteca nativa VCL PDF da losLab, trata a conformidade como algo a declarar antes de a primeira página existir. O utilizador define uma propriedade de conformidade, anexa as estruturas exigidas pela norma e a biblioteca rejeita as configurações que contrariem o perfil no momento da gravação. Trata-se de um modelo preferível a gerar um ficheiro e esperar que um pós-processador o consiga adaptar, uma vez que a maior parte dos requisitos destas normas não pode ser adicionada posteriormente.
Três normas ISO, três promessas distintas
O PDF/A (ISO 19005) foca-se no tempo. Promete que um ficheiro continuará a ser renderizado de forma idêntica daqui a décadas, pelo que exige total autossuficiência: todos os tipos de letra incorporados, todas as cores com significado independente do dispositivo através de um OutputIntent, metadados XMP completos e a proibição de tudo cujo comportamento dependa do ambiente. Encriptação e JavaScript ficam de fora, pois ninguém pode garantir que o descodificador ou o motor de script existam em 2050.
O PDF/X (ISO 15930) foca-se na cor em papel. Existe para que um designer possa entregar um ficheiro a uma tipografia sem necessidade de discussões adicionais, o que implica condições de impressão caraterizadas, uma chave /Trapped obrigatória, geometria definida de margens de corte (trim e bleed) e, na variante X-1a, ausência de transparências ativas para o RIP processar por estimativa. O PDF/UA (ISO 14289) foca-se em quem consegue ler o resultado. A tecnologia de apoio requer uma árvore de etiquetas (tags) completa, uma ordem de leitura lógica, um idioma de documento declarado e alternativas textuais para tudo o que não seja texto.
Como as três normas apontam em direções distintas, selecione a norma orientadora por canal de saída, em vez de tentar criar um único ficheiro que satisfaça todas as exigências. Um master de impressão apenas em CMYK é precisamente o ficheiro errado para entregar a um utilizador com leitor de ecrã que nunca vê a cor, e o bloqueio do perfil de arquivo a comportamentos dinâmicos colide com qualquer elemento interativo. Gere um ficheiro por canal a partir dos mesmos dados de origem e evitará todo o conflito.
PDF/A: o OutputIntent é a parte de que todos se esquecem
Se um ficheiro PDF/A falhar a validação, o OutputIntent é a primeira coisa a verificar. Trata-se da estrutura que os geradores ignoram mais frequentemente, precisamente porque nada de visível depende dela. A norma ISO 19005 exige uma: um perfil ICC incorporado que define o significado real das cores do dispositivo no documento. O HotPDF torna esse perfil um input explícito e não um pormenor secundário:
var
Pdf: THotPDF;
ICC: TFileStream;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'invoice-archival.pdf';
Pdf.PDFACompliance := 'B'; // level B: visual fidelity
Pdf.Lang := 'en-US';
Pdf.StandardFontEmulation := False; // embed real fonts, no Base-14 emulation
ICC := TFileStream.Create('sRGB.icc', fmOpenRead);
try
Pdf.AddPDFAOutputIntent('sRGB IEC61966-2.1', '', ICC, 3, 'DeviceRGB');
finally
ICC.Free;
end;
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 760, 0, 'Archival invoice body');
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;Alguns pormenores determinam o sucesso ou a falha aqui. O StandardFontEmulation tem de estar desativado: os tipos de letra Base-14 emulados não são incorporados, e a incorporação é inegociável sob a norma ISO 19005. A encriptação tem de permanecer desativada, pelo que nunca deve combinar PDFACompliance com ActivateProtection; um ficheiro de arquivo encriptado é uma contradição que o validador deteta de imediato. A contagem de componentes em AddPDFAOutputIntent tem de corresponder ao perfil, que é 3 para um perfil RGB como o sRGB IEC61966-2.1 e 4 para CMYK. O HotPDF monitoriza a utilização de DeviceRGB e DeviceCMYK em relação ao intent declarado à medida que escreve, transformando um preenchimento CMYK inesperado num documento com intent RGB num problema reportado, e não silencioso.
Um aspeto importante sobre o perfil ICC: trate-o como um artefacto de distribuição versionado, e não como um ficheiro que alguém colocou no servidor de compilação. Os seus bytes são incorporados em cada documento gerado, pelo que um perfil truncado ou corrompido contamina silenciosamente todo um lote, algo que só descobrirá no momento da validação. Distribua-o com o seu instalador, registe o seu checksum no log de execução e carregue-o utilizando o padrão TFileStream apresentado acima, para que a ausência do ficheiro falhe ruidosamente durante a geração, em vez de falhar silenciosamente no momento de arquivar.
PDF/X para impressão: Trapped, CMYK e o perfil da prensa
Os masters de impressão invertem a abordagem da cor. A prensa exige CMYK caraterizado, e a norma obriga a declarar se a sobreposição de cores (trapping) foi aplicada, mesmo quando a resposta sincera é que não faz ideia. A chave /Trapped é, de qualquer modo, obrigatória:
Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown'; // mandatory key under ISO 15930
ICC := TFileStream.Create('FOGRA39.icc', fmOpenRead);
try
Pdf.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICC, 4, 'DeviceCMYK');
finally
ICC.Free;
end;
Pdf.BeginDoc;
// draw with CMYK-safe colors, no transparency, no encryption
Pdf.EndDoc;A contagem de componentes é agora 4 para o perfil da prensa CMYK. A norma X-1a também proíbe transparências ativas, pelo que deve auditar qualquer código de desenho que sobreponha elements translúcidos... Wait, elements is English! Let's check original line: "qualquer código de desenho que sobreponha elementos translúcidos;" Yes! "elementos translúcidos" Let's read new_body line again: "A norma X-1a também proíbe transparências ativas, pelo que deve auditar qualquer código de desenho que sobreponha elementos translúcidos; tudo o que um visualizador compõe no ecrã é exatamente o que um RIP recusará interpretar. Quando a tipografia enviar uma caraterização diferente, substitua os bytes do perfil e a string de identificação, mas mantenha a estrutura circundante inalterada." Yes, this is correct.
PDF/UA: a estrutura gera-se, nunca se adapta à posteriori
A acessibilidade é a norma que as equipas mais tentam acrescentar no final, e este método é mais penalizado do que nas outras duas normas. A árvore de etiquetas (tags) tem de refletir a ordem em que o conteúdo foi logicamente criado, informação de que simplesmente já não dispõe depois de o ficheiro ser escrito. A definição de PDFUACompliance ativa o output etiquetado, e a API de estrutura vincula cada chamada de desenho ao seu papel semântico à medida que avança:
Pdf.PDFUACompliance := True; // auto-enables tagged PDF
Pdf.Lang := 'en-US'; // set explicitly; empty falls back to 'en'
Pdf.BeginDoc;
Root := Pdf.AddStructureElement(sstDocument, nil);
H1 := Pdf.EmitTaggedHeading(1, Root, 50, 700, 'Quarterly Report');
Para := Pdf.BeginTaggedContent('P', Root);
Pdf.CurrentPage.TextOut(50, 650, 0, 'Revenue grew in all regions.');
Pdf.EndTaggedContent;
Pdf.EndDoc;A falha a evitar é o desenho de texto fora de qualquer par BeginTaggedContent/EndTaggedContent. O texto é renderizado perfeitamente e permanece invisível para um leitor de ecrã, pelo que nenhum testador visual o detetará; o bug é distribuído e surge apenas quando um utilizador de tecnologia de apoio depara com a lacuna. Quando os seus modelos contiverem nomes de papéis de estrutura personalizados, mapeie-os para o conjunto padrão com AddStructRoleMap('MyHead', 'H1') para que os leitores conformes saibam o seu significado. A norma ISO 14289 também exige um idioma declarado. O HotPDF reverte para 'en' quando o Lang está vazio, mas esta é uma rede de segurança, e não um motivo para deixar o idioma real do documento indefinido.
Validação: confie no validador, não no visualizador
Um visualizador conseguir abrir o seu ficheiro não prova a conformidade, pelo que a validação deve fazer parte do processo de distribuição com ferramentas que verifiquem a estrutura e não o render. Para o PDF/A e PDF/UA, o veraPDF é o validador de código aberto de referência; reporta falhas por cláusula ISO, o que remete diretamente para a configuração acima. Para o PDF/X, os perfis Preflight do Adobe Acrobat continuam a ser a verificação prática, pois a conformidade de impressão prende-se tanto com a intenção da cor como com a sintaxe.
O gerador faz a sua parte neste processo. No momento da gravação, o HotPDF harmoniza as flags de funcionalidades com a versão de PDF configurada, reduzindo silenciosamente o que a versão não consegue expressar, como a transição de AES-256 para AES-128 abaixo do PDF 1.7. As validações de conformidade em EndDoc vão mais além e lançam exceções perante contradições graves, como solicitar a conformidade PDFACompliance em conjunto com encriptação. Nenhuma destas ações substitui o validador externo. Apenas evitam que configurações impossíveis cheguem a ele.
Um hábito que traz vantagens contínuas: versione toda a configuração de conformidade como uma unidade. A versão do HotPDF, a revisão do modelo, o checksum do perfil ICC, a compilação do validador que aprovou o ficheiro. A conformidade desvia-se no momento em que qualquer um deles muda em relação aos restantes, e as auditorias mais complexas são aquelas em que ninguém consegue reconstruir qual a combinação que produziu um ficheiro de arquivo com cinco anos. Um único registo de configuração por lote resolve esta questão de vez.
Por fim, execute o validador no output real de produção, e nunca numa amostra organizada criada manualmente. As falhas mais problemáticas provêm de dados que ninguém antecipou: o logótipo de um cliente que chega em CMYK quando a intenção declara RGB, um ajuste no modelo que insere um tipo de letra não incorporado, um novo caminho no código que desenha texto fora da árvore de etiquetas. Mantenha um ficheiro conhecido como incorreto (known-bad) de cada incidente anterior como input de regressão, e a validação manter-se-á fiável ao longo do tempo. Para a renderização destes pipelines, consulte o nosso artigo sobre a produção de relatórios, tipos de letra e imagens com o HotPDF; para integrar validadores numa compilação, consulte o artigo complementar sobre automação de verificações de preflight de PDF.
As propriedades de conformidade, as intenções de saída (output intents) e a API de etiquetagem utilizadas nestes exemplos são disponibilizadas com o HotPDF Component para Delphi e C++Builder; a página do produto fornece o link para a referência completa de cada chamada apresentada aqui.