NBRISO19005-1 - Arquivo para Impressão

Documento impresso em 31/03/2020 19:46:47, de uso exclusivo de INST. FED. DE EDUC., CIÊNC. E TECN.
RIO DE JANEIRO
NORMA ABNT NBR

BRASILEIRA ISO
19005-1
Primeira edição
23.01.2009
Válida a partir de
Documento impresso em 31/03/2020 19:46:47, de uso exclusivo de INST. FED. DE EDUC., CIÊNC. E TECN. RIO DE JANEIRO
23.02.2009
Gerenciamento de documentos — Formato

eletrônico de arquivo de documento para
preservação de longo prazo
Parte 1: Uso do PDF 1.4 (PDF/A-1)
Document management – Electronic document file format for long term
preservation
Part 1: Use of PDF 1.4 (PDF/A-1)
Palavras-chave: Gerenciamento de documentos. Documento eletrônico. PDF 1.4.

Descriptors: Document management. Eletronic document. PDF 1.4.
ICS 35.240.30; 37.100.99
ISBN 978-85-07-01246-7
Número de referência
ABNT NBR ISO 19005-1:2009
29 páginas
© ISO 2005 - © ABNT 2009


© ISO 2005
Todos os direitos reservados. A menos que especificado de outro modo, nenhuma parte desta publicação pode ser reproduzida
ou utilizada por qualquer meio, eletrônico ou mecânico, incluindo fotocópia e microfilme, sem permissão por escrito da ABNT,
único representante da ISO no território brasileiro.
© ABNT 2009
Todos os direitos reservados. A menos que especificado de outro modo, nenhuma parte desta publicação pode ser reproduzida
ou utilizada por qualquer meio, eletrônico ou mecânico, incluindo fotocópia e microfilme, sem permissão por escrito da ABNT.
ABNT
Av.Treze de Maio, 13 - 28º andar
20031-901 - Rio de Janeiro - RJ
Tel.: + 55 21 3974-2300
Fax: + 55 21 3974-2346
abnt@abnt.org.br
www.abnt.org.br
ii © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

Sumário Página
Prefácio Nacional.......................................................................................................................................................iv
Introdução ...................................................................................................................................................................v
1 Escopo ............................................................................................................................................................1
2 Referências normativas ................................................................................................................................1

3 Termos e definições ......................................................................................................................................2
4 Notação...........................................................................................................................................................4
5 Níveis de conformidade ................................................................................................................................4
5.1 Geral................................................................................................................................................................4
5.2 Nível de conformidade A...............................................................................................................................5
5.3 Nível de conformidade B...............................................................................................................................5
5.4 Leitores conformes .......................................................................................................................................5
6 Requisitos técnicos.......................................................................................................................................5
6.1 Estrutura de arquivo......................................................................................................................................5
6.2 Gráficos ..........................................................................................................................................................7
6.3 Fontes ...........................................................................................................................................................10
6.4 Transparência ..............................................................................................................................................12
6.5 Anotações ....................................................................................................................................................12
6.6 Actions..........................................................................................................................................................13
6.7 Metadados ....................................................................................................................................................14
6.8 Estrutura lógica ...........................................................................................................................................19
6.9 Formulários interativos...............................................................................................................................21
Anexo A (informativo) PDF/A-1 – Sumário de conformidade ...............................................................................22
Anexo B (informativo) Boas práticas para o PDF/A...............................................................................................26
Bibliografia ................................................................................................................................................................28
© ISO 2005 - © ABNT 2009 - Todos os direitos reservados iii

Prefácio Nacional
A Associação Brasileira de Normas Técnicas (ABNT) é o Foro Nacional de Normalização. As Normas Brasileiras,
cujo conteúdo é de responsabilidade dos Comitês Brasileiros (ABNT/CB), dos Organismos de Normalização
Setorial (ABNT/ONS) e das Comissões de Estudo Especiais (ABNT/CEE), são elaboradas por Comissões de
Estudo (CE), formadas por representantes dos setores envolvidos, delas fazendo parte: produtores, consumidores
e neutros (universidade, laboratório e outros).
Os Documentos Técnicos ABNT são elaborados conforme as regras das Diretivas ABNT, Parte 2.
A Associação Brasileira de Normas Técnicas (ABNT) chama atenção para a possibilidade de que alguns dos
elementos deste documento podem ser objeto de direito de patente. A ABNT não deve ser considerada
responsável pela identificação de quaisquer direitos de patentes.
A ABNT NBR ISO 19005-1 foi elaborada pela Comissão de Estudo Especial de Segurança em Documentação
Eletrônica (ABNT/CEE-84), com a colaboração do Organismo de Normalização Setorial de Tecnologia Gráfica
(ABNT/ONS-27). O Projeto circulou em Consulta Nacional conforme Edital nº 11, de 06.11.2008 a 05.12.2008,
com o número de Projeto 00:001.84-001.
Esta Norma é uma adoção idêntica, em conteúdo técnico, estrutura e redação, à ISO 19005-1:2005 e sua Errata
(Cor 1:2007), que foi elaborada pelo Technical Committee Document management applications (ISO/TC 171),
Subcommittee SC 2, Application issues, conforme ISO/IEC Guide 21-1:2005.
A ABNT NBR ISO 19005, sob o título geral “Gerenciamento de documentos – Formato eletrônico de arquivo de
documento para preservação de longo prazo”, tem previsão de conter as seguintes partes:
 Parte 1: Uso PDF 1.4 (PDF/A-1)
O Escopo desta Norma Brasileira em inglês é o seguinte:
Scope
This part of ABNT NBR ISO 19005 specifies how to use the Portable Document Format (PDF) 1.4 for long-term
preservation of electronic documents. It is applicable to documents containing combinations of character,
raster and vector data.
This part of ABNT NBR ISO 19005 does not apply to:
 specific processes for converting paper or electronic documents to the PDF/A format;
 specific technical design, user interface, implementation, or operation details of rendering;
 specific physical methods of storing these documents such as media and storage conditions;
 required computer hardware and/or operating systems.
iv © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

Introdução
O PDF é um formato digital para representar documentos, sejam criados nativamente em PDF, convertidos a partir
de outros formatos eletrônicos ou digitalizados de papel, microfilmes ou outro formato de cópia física.
Empresas, governos, bibliotecas, arquivos e outras instituições e indivíduos espalhados pelo mundo usam o PDF
para representar quantidades importantes de informações. Muitas destas informações devem ser mantidas por
um tempo considerável e outras permanentemente. Estes documentos PDF devem permanecer utilizáveis
e acessíveis ao longo de diversas gerações de tecnologia. O uso e o acesso futuro a estes objetos dependem da
manutenção da aparência visual, assim como de suas propriedades principais, como sua organização lógica de
páginas, seções e parágrafos, streams de texto recuperáveis por equipamentos na ordem natural de leitura e uma
variedade de metadados de administração, preservação e descrição dos documentos.
A Adobe Systems Incorporated disponibilizou publicamente a especificação do PDF. Porém, a natureza rica
de características do formato PDF requer limitações adicionais para seu uso, a fim de torná-lo adequado para
a preservação de longo prazo de documentos eletrônicos.
O objetivo primário desta parte da ABNT NBR ISO 19005 é definir um formato de arquivo baseado no PDF,
conhecido como PDF/A, que provê um mecanismo para representar documentos eletrônicos de maneira
a preservar sua aparência visual ao longo do tempo, independentemente das ferramentas e sistemas utilizados
para criar, armazenar e ler os arquivos.
Um objetivo secundário desta parte da ABNT NBR ISO 19005 é prover uma estrutura para registrar o contexto
e a história dos documentos eletrônicos em metadados dentro de arquivos conformes.
Outro objetivo desta parte da ABNT NBR ISO 19005 é definir um esquema para representar a estrutura lógica
e outras informações semânticas dos documentos eletrônicos dentro de arquivos conformes.
Estes objetivos são atingidos identificando um conjunto de componentes do PDF que podem ser usados,
e restrições na forma de seu uso, dentro de arquivos PDF/A conformes.
Por si só o formato PDF/A não garante necessariamente que a aparência visual do conteúdo seja reflexo preciso
de um original utilizado para criar o arquivo conforme. Por exemplo, o processo utilizado para criar o arquivo
conforme pode ter substituído fontes, corrido o texto, reduzida a resolução de imagens ou utilizado compressão
com perda. As organizações que necessitam ter certeza que os arquivos conformes são uma representação
precisa dos materiais originais podem impor ulteriores restrições nos processos de geração de arquivos conformes
além daqueles impostos por esta parte da ABNT NBR ISO 19005. Além disso, é importante para estas
organizações implementar políticas e práticas em relação à inspeção dos arquivos conformes para verificar
a correção da aparência visual.
Convém que esta parte da ABNT NBR ISO 19005 seja utilizada pelas organizações como um ambiente de
arquivamento de dados por longo prazo de retenção de documentos. A implementação bem-sucedida desta parte
da ABNT NBR ISO 19005 para efeito de arquivamento depende de:
 requisitos de retenção do ambiente de arquivamento de longo prazo da organização, políticas de records

[9]
management e procedimentos segundo especificado na ISO 15489-1, ;
 quaisquer outros requisitos e condições necessárias para assegurar a persistência de documentos,

eletrônicos e suas características ao longo do tempo, incluindo, mas não se limitando, aos definidos em:
 ISO 14721;
© ISO 2005 - © ABNT 2009 - Todos os direitos reservados v

 ISO/TR 15801, [10];
 ISO/TR 18492, [12];
 ISO 18509-1, [13];
 ISO 18509-2, [14];

 processos de garantia de qualidade necessários para verificar a conformidade com aplicação dos requisitos
e condições, por exemplo, um regime de inspeção, a fim de verificar a qualidade e integridade das fontes de
dados de conversão.
Convém que esta parte da ABNT NBR ISO 19005 conduza ao desenvolvimento de várias aplicações que lêem,
renderizam, gravam e validam arquivos conformes. Diferentes aplicações incorporarão diversas capacidades,
a fim de preparar, interpretar e processar arquivos conformes baseados nas necessidades percebidas pelos
fornecedores destas. Porém, é importante notar que uma aplicação conforme deve ser capaz de ler e processar
adequadamente todos os arquivos conformes a um determinado nível de conformidade.
Este documento foi criado como a Parte 1 da ABNT NBR ISO 19005, a fim de permitir a criação de futuras partes,
que deverão prover compatibilidade com futuras especificações do formato subjacente PDF, sem que este
documento ou aplicações baseadas no PDF versão 1.4 fiquem obsoletos.
Os seguintes termos, referências a esta especificação ou suas partes, são recomendados quando não for utilizado
o nome ISO completo desta Norma:
 “PDF/A” – um sinônimo para a família ISO 19005;
 “PDF/A-1” – um sinônimo para a ISO 19005-1;
 “PDF/A-1a” – um sinônimo para a ISO 19005-1 Nível de conformidade A;
 “PDF/A-1b” – um sinônimo para a ISO 19005-1 Nível de conformidade B.
Esta parte da ABNT NBR ISO 19005, em conjunto com o Manual de Referência PDF e a Especificação XMP, de
janeiro de 2004, provê informação suficiente para interpretar qualquer arquivo PDF/A conforme. O Manual de
Referência PDF contém uma declaração da Adobe Systems Incorporated em relação à propriedade intelectual
e sua intenção de permitir o uso perpétuo, não exclusivo e sem cobrança de royaltys daquela tecnologia, de
maneira a promover o uso do PDF. A Adobe forneceu à ISO uma declaração similar relativa à tecnologia de
Especificação XMP. Em geral qualquer pessoa pode utilizar o Manual de Referência PDF e a Especificação XMP
para criar aplicações que lêem, gravam ou processam arquivos PDF/A.
Reivindicações de patentes em relação às aplicações que lêem, gravam ou processam arquivos PDF/A estão fora
do escopo desta parte da ABNT NBR ISO 19005.
A NPES e a AIIM, organizações acreditadas para o desenvolvimento de normas, mantêm uma série de application
notes para guiar os desenvolvedores e usuários desta parte da ABNT NBR ISO 19005. Estes application notes
estão disponíveis nos endereços <http://www.npes.org/standards/toolspdfa.html> e <http://www.aiim.org/pdfa/
app-notes>. Tanto a NPES quanto a AIIM terão também cópias das referências normativas não-ISO desta parte
da ABNT NBR ISO 19005, publicamente disponibilizadas como documentos eletrônicos.*
* NOTA DA TRADUÇÃO: Application Notes são textos para orientar desenvolvedores na utilização da Norma..
vi © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

NORMA BRASILEIRA ABNT NBR ISO 19005-1:2009
Gerenciamento de documentos — Formato eletrônico de arquivo de

documento para preservação de longo prazo
Parte 1: Uso do PDF 1.4 (PDF/A-1)
1 Escopo
Esta parte da ABNT NBR ISO 19005 especifica como utilizar o Portable Document Format (PDF) 1.4 para
a preservação de longo prazo de documentos eletrônicos. É aplicável a documentos contendo combinações
de dados tipos de caracteres, imagens raster ou vetor.
Esta parte da ABNT NBR ISO 19005 não se aplica a:
 processos específicos para conversão de papel ou documentos eletrônicos no formato PDF/A;
 projeto técnico específico, interfaces de usuário, implementações ou detalhes operacionais de representação;
 métodos físicos específicos para a armazenagem destes documentos como mídia ou condições de
armazenagem;
 requisitos de hardware, software e/ou sistemas operacionais de computadores.
2 Referências normativas
Os documentos relacionados a seguir são indispensáveis à aplicação deste documento. Para referências datadas,
aplicam-se somente as edições citadas. Para referências não datadas, aplicam-se as edições mais recentes do
referido documento (incluindo emendas).
ISO/IEC 646, Information Technology — ISO 7-bit coded character set for information interchange.
NOTA 1 A codificação de caracteres definida na ISO/IEC 646 é equivalente à ANSI X3.4 (ASCII) [1] e ECMA-6 [2].
ISO/IEC 9541-1, Information technology — Font information interchange — Part 1: Architeture
ISO/IEC 10646-1, Information technology — Universal Multiple-Octet Coded Character Set (UCS) —
Part 1: Architeture and Basic Multilingual Plane
NOTA 2 Os valores de caractere definidos na ISO/IEC 10646-1 são equivalentes ao Unicode [22].
ISO 14721, Space data and information transfer systems — Open archival information system — Reference model
ISO 15930-4, Graphic Technology — Prepress digital data exchange using PDF — Part4: Complete exchange
of CMYK and spot colour printing data using PDF 1.4 (PDF/X-1a)
Date and Time Formats, W3C Note, 15 September 1997. Disponível na Internet no endereço
<http://www.w3.org/TR/NOTE-datetime>
Errata for PDF Reference, third edition, 18 de junho de 2003. Disponível na Internet no endereço
<http://partners.adobe.com/asn/acrobat/docs/ PDF14errata.pdf>
© ISO 2005 - © ABNT 2009 - Todos os direitos reservados 1

Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, 4 de Fevereiro de 2004.
Disponível na Internet no endereço <http://www.w3.org/TR/2004/REC-xml-20040204>
ICC.1A:1998-09, File Format for Color Profiles, International Color Consortium. Disponível na Internet no endereço
<http://www.color.org/ICC-1A 1999-04.PDF>
PDF Reference: Adobe Portable Document Format, Version 1.4, Adobe Systems Incorporated – 3rd ed.
(ISBN 0-201-75839-3). Disponível na Internet no endereço <http://partners.adobe.com/asn/acrobat/docs/File
Format Specifications/PDFReference.pdf>
RDF/XML Syntax Specification (Revised), W3C Recommndation, 10 de fevereiro de 2004. Disponível na Internet
no endereço <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/>
Tags for the Identification of Languages, RFC 1766, Março de 1995. Disponível na Internet no endereço
<http://www.ietf.org/ rfc/rfc1766.txt>
XMP Specification, novembro de 2003 (em preparação), Adobe Systems Incorporated
NOTA 3 A AIIM e a NPES, organizações acreditadas para desenvolvimento de normas, mantêm cópias das referências
não-ISO de documentos disponibilizados publicamente.
3 Termos e definições
Para os efeitos deste documento, aplicam-se os seguintes termos e definições.
3.1
nível de conformidade
conjunto identificado de restrições e requisitos ao qual arquivos e leitores devem ser conformes
[ISO 15930-4]
3.2
tabela de referência cruzada
estrutura de dados do PDF que contém a distância em bytes do início de cada objeto indireto, dentro do arquivo
3.3
dicionário
tabela associativa contendo pares de chaves e valores, especificando o nome e o valor de um atributo para
objetos, que geralmente é utilizada para colecionar e relacionar os atributos de um objeto complexo
[ISO 15930-4]
3.4
documento eletrônico
representação eletrônica de um agregado de textos, gráficos e metadados para identificação, descritos como
página, que podem ser reproduzidos em papel ou microfilme sem perda significativa de seu conteúdo de
informação
3.5
marca end-of-file
seqüência de cinco caracteres %%EOF marcando o final de um arquivo PDF
2 © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

3.6
marca end-of-line
(EOL marker)
seqüência de um ou dois caracteres marcando o final de uma linha de texto, consistindo no caractere CARRIAGE
RETURN (0Dh) ou o LINE FEED (0Ah) ou um CARRIAGE RETURN, seguido imediatamente de um LINE FEED
3.7
fonte
coleção identificada de gráficos que podem ser glifos ou outros elementos gráficos
[ISO 15930-4]
3.8
glifo
símbolo gráfico abstrato reconhecível que é independente de qualquer design
[ISO/IEC 9541-1]
3.9
perfil ICC
perfil de cores em conformidade com a especificação ICC e seus adendos
[ICC.1:1998-09] e [ICC.1A:1999-04]
3.10
leitor interativo
leitor que requer ou permite interação humana durante a fase de processamento de software
NOTA Uma ferramenta de visualização de arquivos é um exemplo de leitor interativo. Um RIP (Raster Image Processor)
é um exemplo de um leitor não interativo.
3.11
Nível de conformidade A
nível de conformidade que engloba todos os requisitos desta parte da ABNT NBR ISO 19005
3.12
nível de conformidade B
nível de conformidade que engloba os requisitos desta parte da ABNT NBR ISO 19005 em relação à aparência
visual dos documentos eletrônicos, mas não sua estrutura ou propriedades semânticas
3.13
longo prazo
período de tempo suficientemente longo para que se tenha preocupação quanto aos impactos das mudanças de
tecnologia, inclusive suporte a novas mídias e formatos de dados e mudanças na comunidade de usuários,
sobre um repositório de informação. Este período pode se estender por tempo indefinido no futuro
[ISO 14721]
3.14
PDF
Portable Document Format
Formato de arquivo definido no Manual de Referencia PDF e suas Erratas
[ISO 15930-4]
3.15
leitor
aplicação de software que tem a habilidade de ler e processar arquivos corretamente
[ISO 15930-4]

3.16
caractere espaço
caractere tipo string de texto usado para representar o espaço em branco ortográfico como argumento
em operações de escrita de texto
NOTA Caracteres comumente utilizados são o HORIZONTAL TABULATION (U+0009), LINE FEED (U+000A),
VERTICAL TABULATION (U+000B), FORM FEED (U+000C), CARRIAGE RETURN (U+000D), SPACE (U+0020),
NO-BREAK SPACE (U+00A0), EN SPACE (U+2003), EM SPACE (U+2003), ZERO WIDTH SPACE (U+200B) e
IDEOGRAPHIC SPACE (U+3000).
3.17
caractere de espaço em branco
NULL (00h), HORIZONTAL TABULATION (09h), LINE FEED (0Ah), FORM FEED (0Ch), CARRIAGE RETURN
(0Dh) ou SPACE (20h)
3.18
gravador
aplicação de software que tem a habilidade de gravar arquivos
[ISO 15930-4]
3.19
pacote XMP
invólucro estruturado para metadados serializados que pode ser embutido em uma variedade de formatos
de arquivos
4 Notação
Operadores PDF, palavras-chave PDF, nomes de chaves em dicionários PDF e outros nomes predefinidos
são escritos em fonte sem serifa em negrito; operando de operadores PDF ou valores de chaves de dicionários
são escritos em fonte italizada sem serifa.
EXEMPLO O valor Default da chave TR2.
Os caracteres tipo token utilizados para delimitar objetos e descrever a estrutura de arquivos PDF, assim como
definido no PDF Reference 3.1, podem ser identificados pelo seu nome de caractere ISO/IEC 646 escrito
em maiúscula numa fonte sem serifa em negrito, seguida por dois caracteres entre parênteses e um sufixo "h".
EXEMPLO CARRIAGE RETURN (0Dh).
Caracteres tipo strings de texto em conteúdos stream, assim como definido no PDF Reference 3.8.1, podem ser
identificados pelo seu nome de caractere ISO/IEC 10646-1 escrito em maiúscula numa fonte sem serifa
em negrito, seguida por quatro caracteres entre parênteses e um prefixo "U+".
EXEMPLO EN SPACE (U+2002).
Para o propósito desta parte da ABNT NBR ISO 19005, as referências ao “PDF Reference” são referências
ao documento "Adobe Portable Document Format, versão 1.4, 3ª edição".
5 Níveis de conformidade
5.1 Geral
Esta parte da ABNT NBR ISO 19005 define um formato de arquivo para representar documentos eletrônicos
conhecidos como “PDF/A-1”. Arquivos conformes PDF/A-1 devem aderir a todos os requisitos do PDF Reference
assim como foram modificados por esta parte da ABNT NBR ISO 19005. Um arquivo conforme pode incluir
qualquer característica do PDF Reference que não seja explicitamente proibida por esta parte da
ABNT NBR ISO 19005. Convém que as características descritas nas especificações PDF anteriores à versão 1.4
que não forem explicitamente descritas no PDF Reference não sejam usadas. Tanto o valor do número da versão

do PDF no seu cabeçalho quanto o valor da chave Version no dicionário catalog do documento não devem ser
utilizados para se determinar se um arquivo está de acordo com esta parte da ABNT NBR ISO 19005.
NOTA 1 Um arquivo conforme não é obrigado a usar nenhuma característica que não aquelas requeridas pelo PDF
Reference ou esta parte da ABNT NBR ISO 19005.
NOTA 2 O mecanismo adequado pelo qual um arquivo pode presumidamente identificar-se como sendo um arquivo
PDF/A-1, de um determinado nível de conformidade, está descrito em 6.7.11.
5.2 Nível de conformidade A

Arquivos conformes o nível A devem aderir a todos os requisitos desta parte da ABNT NBR ISO 19005.
O arquivo encontrado com este nível de conformidade é chamado "arquivo PDF/A-1a conforme."
5.3 Nível de conformidade B

Em reconhecimento aos vários quesitos de preservação das diversas comunidades de usuários de arquivos PDF,
esta parte da ABNT NBR ISO 19005 define um Nível B de conformidade. Arquivos conformes o Nível B devem
aderir a todos os requisitos desta parte da ABNT NBR ISO 19005, exceto os descritos em 6.3.8 e 6.8. Um arquivo
que atenda a este nível de conformidade é chamado "arquivo PDF/A-1b conforme."
NOTA Os requisitos do Nível de conformidade B têm a intenção de ser aqueles mínimos necessários, a fim de assegurar
que a aparência visual representada do arquivo conforme seja preservada ao longo do tempo. Porém, arquivos Nível B
conformes podem não ter conteúdo suficientemente rico para permitir a preservação a longo prazo de sua estrutura lógica
e fluxos de texto na ordem de leitura natural, previstos pelo Nível de conformidade A. Os requisitos do Nível de conformidade A
colocam grande responsabilidade nos gravadores de arquivos conformes e àqueles que os preparam, mas estes requisitos
garantem um maior nível de preservação dos documentos e maior confiabilidade no tempo. Além do mais, o Nível A
de conformidade facilita o acesso aos arquivos conformes a pessoas com deficiências físicas.
5.4 Leitores conformes

Um leitor conforme deve aquiescer a todos os requisitos em relação à funcionalidade de um leitor, especificados
nesta parte da ABNT NBR ISO 19005. Os requisitos desta parte da ABNT NBR ISO 19005, em relação ao
comportamento do leitor, são colocados em termos de funcionalidades gerais necessárias a todo leitor conforme.
Esta parte da ABNT NBR ISO 19005 não especifica nenhum projeto técnico específico, interface de usuário
ou detalhes de implementação aos leitores conformes.
A representação de arquivos conformes deve ser feita assim como definido no PDF Reference sujeito aos
anteriores requisitos especificados por esta parte da ABNT NBR ISO 19005. Características descritas nas
especificações PDF anteriores à Versão 1.4 que não forem explicitadas no PDF Reference podem ser ignoradas
pelos leitores conformes.
Leitores conformes devem ler e processar adequadamente todos os arquivos PDF/A-1 conformes a um nível de
conformidade específico. Leitores Nível A conformes devem ler e processar todos os arquivos Níveis A e B
conformes. Leitores Nível B conformes devem ler e processar todos os arquivos Nível B conformes.
6 Requisitos técnicos
6.1 Estrutura de arquivo
6.1.1 Geral
As alíneas de 6.1.2 a 6.1.13 tratam de questões gerais do formato e dos elementos básicos que constituem
a estrutura de um arquivo conforme.
6.1.2 File header
O caractere % do cabeçalho do arquivo deve ocorrer no byte de offset 0, no arquivo.

A linha do cabeçalho do arquivo deve ser seguida imediatamente por um comentário, consistindo em um caractere
% seguido por pelo menos quatro caracteres; cada um dos quais deve ter o byte de valor de codificação com valor
decimal acima de 127. *1
NOTA A presença de caracteres com byte de valor de codificação com valor decimal acima de 127 no início de arquivos
é utilizada por vários softwares e protocolos para classificar o arquivo em questão como contendo dados binários de 8 bits
e que convém preservar durante o processamento.
6.1.3 File trailer

O dicionário da cauda de um arquivo deve conter a chave ID. A chave Encrypt não deve ser utilizada no dicionário
trailer. Nenhum dado deve se localizar apos o último marcador de fim-de-arquivo, exceto um único caractere
marcador opcional end-of-line.
O dicionário referido é tanto o último dicionário da cauda em um arquivo PDF, assim como descrito no PDF
Reference 3.4.4 e 3.4.5, ou o dicionário de primeira página em um arquivo PDF linearizado, assim como descrito
no PDF Reference F2. Em um arquivo PDF linearizado, a chave ID deve estar presente tanto no dicionário de
primeira página quanto no dicionário da cauda do arquivo e os valores de ambas as ocorrências devem ser
idênticos.**2
NOTA A proibição explícita da chave Encrypt tem o efeito implícito de proibir permissões de acesso por senhas
e criptografia.
6.1.4 Cross reference table
Na subseção cross reference do cabeçalho, o número do objeto inicial e sua distância devem ser separados
por um único caractere de espaço, SPACE (20h).
A chave xref e a subseção cross reference devem ser separadas por um único caractere marcador EOL.
Qualquer objeto cujo offset não seja referenciado na tabela de referência cruzada deve estar isento de qualquer
requisito desta parte da ABNT NBR ISO 19005.
6.1.5 Document information dictionary
Um document information dictionary pode ser definido em um arquivo conforme. Se definido, seus elementos
devem ser consistentes com as propriedades análogas dos metadados XMP, como especificado em 6.7.3.
6.1.6 Objetos tipo string
Strings hexadecimais devem conter um número ímpar de caracteres espaços-não-brancos, cada um de 0 a 9, A

a F ou a a f.
6.1.7 Objetos tipo stream

A chave Stream deve ser seguida por uma seqüência de um CARRIAGE RETURN (0Dh) e um LINE FEED (0Ah)
ou por um único LINE FEED. A chave endstream deve ser precedida por um marcador EOL.
O valor da chave Lenght especificado no dicionário stream deve ter um número de bytes equivalente do arquivo
desde após o caractere LINE FEED após a chave stream até o marcador EOL antes da chave endstream.
NOTA 1 Estes requisitos removem potenciais ambigüidades em relação ao final do conteúdo do stream.
Um dicionário de objeto stream não deve conter as chaves F, Ffilter ou FDecodeParams.
* NOTA DA TRADUÇÃO: Offset em um arquivo é a distância em bytes em relação ao início do arquivo

** NOTA DA TRADUÇÃO: Chamou-se de dicionário de primeira página o termo first-page trailer

NOTA 2 Estas chaves são utilizadas para apontar para conteúdos do documento externos ao arquivo. A proibição explícita
destas chaves tem o efeito implícito de proibir conteúdos externos que poderiam criar dependências externas e complicar
os esforços de preservação.
6.1.8 Objetos indiretos
O número do objeto e o número de geração devem ser separados por um único caractere de espaço em branco.
O número de geração e a chave obj devem ser separados por um único caractere de espaço em branco.
O número do objeto e a chave endobj devem cada qual ser precedidos por um marcador EOL. As chaves obj
e endobj devem ser cada uma seguida de um marcador EOL.
6.1.9 PDF linearizado

A linearização deve ser permitida, porém convém que qualquer informação sobre linearização contida nos
arquivos seja ignorada pelos leitores.
6.1.10 Filtros
O filtro LZWDecode não deve ser permitido.
NOTA O uso do algoritmo de compressão LZW foi submetido a limitações de propriedade intelectual.
6.1.11 Arquivos embutidos
Um file specification dictionary, como definido em PDF 3.10.2, não deve conter a chave EF. Um file specification
dictionary, como definido no PDF Reference 3.6.3, não deve conter a chave EmbeddedFiles.
NOTA Estas chaves são utilizadas para encapsular arquivos com conteúdo arbitrário dentro de um arquivo PDF.
A proibição explícita destas chaves tem o efeito implícito de proibir o uso de arquivos embutidos que podem criar dependências
externas e complicar os esforços de preservação.
6.1.12 Limites de implementação
Um arquivo conforme não deve violar nenhum dos limites da arquitetura PDF especificados no PDF Reference
Tabela C.1.
NOTA Ao acordar com estes limites, um arquivo conforme é compatível com a maior abrangência de leitores.
6.1.13 Conteúdo opcional
O document catalog dictionary não deve conter a chave com o nome OCProperties.
NOTA A proibição explícita da chave OCProperties, que é permitida no PDF 1.5 t[19], tem o efeito implícito de proibir
conteúdos opcionais que gerem representações alternativas do documento.
6.2 Gráficos
6.2.1 Geral
Em 6.2.2 a 6.2.10 está a descrição das restrições para arquivos e leitores conformes. Elas têm a intenção de
atender a questões gerais de representação gráfica que não envolvam fontes e elementos interativos.
6.2.2 Output intent
Um arquivo conforme pode especificar as características de cores do periférico no qual se esperou criar
a representação, utilizando-se o Outputlntent do PDF/A-1. O Outputlntent do PDF/A-1 é um Outputlntent dictionary,
como definido no PDF Reference 9.10.4, que está incluído na matriz Outputlntents do arquivo e tem a chave S
com o valor GTS_PDFA1 e um stream de perfil ICC válido como valor de sua chave DestOutputProfile.
Se a matriz Outputlntents de um arquivo contiver mais de uma entrada, então todas as entradas que contêm
uma chave DestOutputProfile devem ter como valor destas chaves o mesmo objeto indireto, que deve ser
um stream de perfil ICC válido.

6.2.3 Espaços de cor
6.2.3.1 Geral
Todas as cores devem ser especificadas de uma maneira device-independent, seja diretamente pelo uso de um
espaço de cores device-independent, ou indiretamente pelo uso de um Outputlntent. Um arquivo conforme pode
utilizar qualquer um dos espaços de cor especificados no PDF Reference, exceto as restrições de 6.2.3.2
a 6.2.3.4.
NOTA Especificar cores na maneira device-independent descrita em 6.2.3 permite reproduções previsíveis de cor baseadas
em definições colorimétricas e sem contar com informações externas ao arquivo conforme. Também provê um mecanismo pelo
qual uma definição colorimétrica pode ser associada com dados de cor device-dependent.
6.2.3.2 Espaços de cor ICCBased
Todos os espaços de cor ICCBased devem ser embutidos como streams de perfis ICC como descrito no PDF
Reference 4.5.
Um leitor conforme deve reproduzir espaços de cor ICCBased assim como é especificado na especificação ICC,
e não deve usar o espaço de cor Alternate especificado no dicionário do stream do perfil ICC.
6.2.3.3 Espaços de cor não calibrados
Um arquivo conforme pode utilizar o espaço de cor DeviceRGB ou DeviceCMYK, mas não deve usar ambos.
Se um espaço de cor não calibrado for utilizado num arquivo, então este arquivo deve conter o Outputlntent do
PDF/A-1, como descrito em 6.2.2. DeviceRGB pode ser utilizado somente se o arquivo contiver um Outputlntent
PDF/A-1 que utiliza o espaço de cor RGB. DeviceCMYK pode ser utilizado somente se o arquivo contiver um
Outputlntent PDF/A-1 que utiliza o espaço de cor CMYK.
Quando representar uma especificação de espaço de cor DeviceGray em um arquivo cujo Outputlntent
é um perfil RGB, um leitor conforme deve converter a especificação de cor DeviceGray para RGB segundo
o método descrito no PDF Reference 6.2.1.
Quando representar uma especificação de espaço de cor DeviceGray em um arquivo cujo Outputlntent
é um perfil CMYK, um leitor conforme deve converter a especificação de cor DeviceGray para DeviceCMYK
segundo o método descrito no PDF Reference 6.2.2.
Quando representando cores especificadas em um espaço de cores device-dependent, um leitor conforme deve
usar o dicionário Outputlntent PDF/A-1 do arquivo, como descrito em 6.2.2, como o espaço de cor de origem.
6.2.3.4 Espaços de Separation e DeviceN

Um leitor conforme deve obedecer às seguintes regras quando representar espaços de cor baseados nos espaços
de cor DeviceN ou Separation.
 Se os colorantes nomeados em um espaço de cores forem todos da lista Ciano, Magenta, Amarelo, Preto,
se o arquivo contiver um Outputlntent e este Outputlntent for um perfil CMYK, então os colorantes devem
ser tratados como componentes do espaço de cor especificado pelo dicionário Outputlntent do PDF/A-1,
como definido em 6.2.2, e o espaço de cor alternate não deve ser utilizado.
 Se o equipamento de saída não suportar os colorantes de espaços de cor Separation ou DeviceN, o espaço
de cor Alternate deve ser utilizado.
O espaço de cor Alternate de um espaço de cor Separation ou DeviceN deve obedecer às restrições sobre
espaços de cor especificados em 6.2.3.2 e 6.2.3.3.
6.2.4 Imagens
Um dicionário Image não deve conter as chaves Alternates ou OPI.

Se um dicionário Image contiver a chave Interpolate, seu valor deve ser false.

O uso da chave Intent deve ser conforme as regras dadas em 6.2.9.

6.2.5 Objeto Form XObjects
Um dicionário XObject tipo form não deve conter nenhuma das seguintes chaves:
 a chave OPI;
 a chave Subtype2 com valor PS;

 a chave PS.
NOTA Nas versões anteriores do PDF, a chave Subtype2 com valor PS e a chave PS eram usadas para determinar
streams arbitrários de código PostScript, que têm o potencial de interferir com a representação confiável do documento.
6.2.6 XObjects tipo Reference
Um arquivo conforme não deve conter nenhum XObject tipo reference.

NOTA XObjects tipo reference se referem a conteúdos arbitrários do documento em arquivos externos ao PDF, criando
assim dependências externas que complicam os esforços de preservação.
6.2.7 XObjects tipo PostScript
Um arquivo conforme não deve conter nenhum XObject tipo PostScript.

NOTA XObjects tipo PostScript contêm streams de código executável arbitrário PostScript que têm o potencial de interferir
com a representação confiável e previsível do documento.
6.2.8 Extended graphics state
Um dicionário ExtGState não deve conter a chave TR. Um dicionário ExtGState não deve conter a chave TR2
com valor diferente de Default. Um leitor conforme pode ignorar qualquer instância da chave HT no dicionário
ExtGState.
O uso da chave RI deve ser conforme as regras de 6.2.9.
6.2.9 Rendering intents
Onde um rendering intent for especificado, seu valor deve ser um dos quatro valores definidos no PDF Reference:
RelativeColorimetric, AbsoluteColorimetric, Perceptual ou Saturation.
NOTA O rendering intent padrão é o RelativeColorimetric.
6.2.10 Content streams
Um stream de conteúdo não deve conter nenhum operador não definido no PDF Reference, mesmo se este
estiver no interior de chaves de operadores de compatibilidade BX/EX.
O uso do operador ri deve ser conforme as regras de 6.2.9.
NOTA 1 Os streams de conteúdo são usados para descrição de páginas, por exemplo: um stream Contents de um objeto
de página com um XObject tipo form, um stream de aparência tipo annotation ou campos de formulários ou anotações Widget.
NOTA 2 Nas versões anteriores do formato PDF era definido o operador PostScript, PS. Não sendo definido no PDF
Reference, seu uso é implicitamente proibido por 6.2.10.

6.3 Fontes
6.3.1 Geral
A intenção dos requisitos de 6.3.2 a 6.3.8 é assegurar que as futuras visualizações dos conteúdos textuais de
arquivos conformes equivalham, em cada glifo, à aparência estática de um arquivo originalmente criado
e permitam a recuperação das propriedades semânticas de cada caractere do conteúdo textual.
6.3.2 Tipos de fontes

Todas as fontes usadas em um arquivo conforme devem ser conforme a especificação de fonte definidas no PDF
Reference 5.5.
Para o propósito desta parte da ABNT NBR ISO 19005, fontes tipo multiple master devem ser consideradas um
caso especial de fontes Type 1; qualquer requisito declarado explicitamente em relação às fontes Type 1
é implicitamente requisito para as fontes multiple master.
NOTA É responsabilidade do gravador assegurar a conformidade de todas as fontes. Esta parte da ABNT NBR ISO 19005
não prescreve a maneira pela qual a conformidade das fontes é determinada.
6.3.3 Fontes composite
6.3.3.1 Geral
Para cada fonte composta (Type 0) referenciada dentro de um arquivo conforme, as entradas CIDSystemlnfo nos
seus dicionários CIDFont e CMap devem ser compatíveis, assim como descrito em 5.6.2 no PDF Reference;
em outras palavras, as palavras strings Registry e Ordering nos dicionários CIDSystemlnfo para aquela fonte
devem ser idênticas, a menos que o valor da chave UserCMap no dicionário CMap seja Identity-H ou Identity-V.
6.3.3.2 Fontes tipo CIDFont
Para todas as fontes CIDFonts Type 2, o dicionário CIDFont deve conter entrada CIDToGIDMap que deve ser
um stream mapeando os CID para os índices de glifos ou o nome Identity, como descrito na Tabela 5.13 do PDF
Reference.
6.3.3.3 CMaps
Todos os CMaps usados dentro de um arquivo conforme, exceto Identity-H e Identity-V, devem ser embutidos
naquele arquivo como descrito no PDF Reference 5.6.4. Para aqueles CMaps embutidos, o valor inteiro da
entrada WMode no dicionário CMap deve ser idêntico ao valor de WMode embutido no stream CMap.
6.3.4 Programas de fontes embutidas
Os programas de fontes para todas as fontes utilizadas em um arquivo conforme devem ser embutidos no arquivo,
como definido em 5.8 do PDF Reference, exceto quando as fontes são utilizadas exclusivamente dentro de textos
com text rendering mode 3. Uma fonte é considerada usada se qualquer um de seus glifos for referenciado
em um dos seguintes contextos:
 um stream Contents de um page object;
 um stream de um Form XObject;
 um appearance stream de um anotation, inclusive campos de formulários;
 um stream de conteúdo de um glifo de fonte Type 3;
 um stream de um padrão azulejado (tiling pattern).
Devem ser utilizadas somente fontes que forem legalmente embutíveis em arquivos para uso ilimitado e universal.

Todos os leitores conformes devem utilizar as fontes embutidas e não fontes residentes localmente em seus
sistemas, simulando-as ou substituindo-as, a fim de reproduzir o arquivo.
NOTA 1 Conforme discutido em 5.2.5 do PDF Reference, o rendering mode 3 de texto especifica que os glifos não são
bordejados, preenchidos ou utilizados como limite de recorte (clipping boundary). Uma fonte utilizada somente neste modo é,
portanto, não representada e assim isenta do requisito de ser embutida.
NOTA 2 Não há isenção para os requisitos de 6.3.4 para as 14 fontes padrão Type 1. As fontes Type 3 são isentas dos
requisitos de 6.3.4, pois a maneira pela qual as fontes Type 3 são definidas garante que elas serão sempre embutidas dentro
de um arquivo PDF, mesmo se o mecanismo para embutir as fontes no arquivo PDF for diferente dos citados em 5.8 do PDF
Reference.
NOTA 3 Os requisitos para metadados de programas de fontes são descritos em 6.7.10.
NOTA 4 Como declarado em 6.3.5, subconjuntos de fontes (font subsets) são aceitos, desde que o programa de fonte proveja
definição dos glifos para todos os caracteres referenciados dentro daquele arquivo. Ao se embutir os programas de fontes
permite-se que os leitores conformes possam reproduzir corretamente todos os glifos na maneira como estes foram
originalmente criados sem a necessidade de qualquer referência a qualquer possível dado ou recurso efêmero externo.
NOTA 5 Esta parte da ABNT NBR ISO 19005 exclui a possibilidade de embutir fontes cujas licenças dependem de acordo
especial com o detentor do copyright da fonte. Tal permissão daria lugar a obrigações inaceitáveis sobre um arquivo
no momento de verificar a existência, validade e longevidade de tais direitos.
6.3.5 Subconjuntos de fontes
Como declarado em 6.3.4, os programas de fontes embutidos devem definir todos os glifos referenciados para
reproduzir um arquivo conforme. Subconjuntos de fontes Type 0 CIDFont, Type 1 e TrueType, de acordo com
o descrito em 5.5.3 no PDF Reference, podem ser usados, desde que os programas de fontes embutidos definam
todos os glifos apropriados.
Para todos os subconjuntos de fontes Type 1 referenciados em um arquivo conforme, o dicionário font descriptor
deve incluir uma string CharSet listando os nomes dos caracteres definidos no subconjunto da fonte, como
descrito na Tabela 5.18 do PDF Reference.
Para todos os subconjuntos CIDFont referenciados em um arquivo conforme, o dicionário font descriptor deve
incluir um stream CIDSet identificando quais CIDs estão presentes no arquivo de fonte CIDFont embutido,
como descrito na Tabela 5.20 do PDF Reference.
NOTA O uso de subconjuntos de fontes eventualmente acarreta uma redução substancial no tamanho dos arquivos
conformes.
6.3.6 Métrica de fontes
Para cada fonte embutida em um arquivo conforme e usado para reprodução, as informações dos glifos
armazenadas na entrada Widths do dicionário da fonte e no programa da fonte embutida devem ser consistentes.
NOTA Este requisito é necessário para de assegurar a representação previsível das fontes, independentemente
se o leitor utiliza as métricas na entrada Widths ou aquelas no programa da fonte.
6.3.7 Codificação de caracteres
Todas as fontes não-simbólicas tipo TrueType devem especificar como valores da entrada Encoding
do dicionários de fonte MacRomanEncoding ou WinAnsiEncoding. Todas as fontes simbólicas tipo TrueType não
devem especificar uma entrada Encoding no dicionário de fonte, e as tabelas ‘cmap’ de seus programas de fontes
devem conter exatamente uma codificação (encoding).
NOTA Este requisito faz normativas as orientações descritas em 5.5.5 do PDF Reference.

6.3.8 Mapeamento de caracteres Unicode
O descrito em 6.3.8 é aplicável somente para arquivos que atinjam o Nível A de conformidade. Para o Nível B de
conformidade, os requisitos de 6.3.8 podem ser ignorados.
O dicionário fonte deve incluir uma entrada ToUnicode cujo valor é um objeto stream CMap que mapeia
os códigos de caractere para valores Unicode [22], como descrito em 5.9 do PDF Reference, a menos que a fonte
atinja ao menos uma das seguintes condições:
 fontes que usam as codificações predefinidas MacRomanEncoding, MacExpertEncoding ou
WinAnsiEncoding, ou que usam os CMaps predefinidos Identity-H ou identity-V;
 fontes Type 1 cujos nomes de caracteres são tirados do conjunto Adobe standard Latin character set ou do
conjunto de caracteres nomeados pela fonte Symbol, como definido no Apêndice D do PDF Reference;
 fontes Type 0 cujos CIDFont descendentes usam as coleções de caracteres Adobe-GB1, Adobe-CNS1,
Adobe-Japan1 ou Adobe-Korea1.
NOTA O mapeamento Unicode permite a recuperação das propriedades semânticas de cada caractere referenciado
no arquivo.
6.4 Transparência
Se uma chave SMask aparecer em um dicionário ExtGState ou XObject, seu valor deve ser None.
Um objeto Group com uma chave S com valor Transparency não deve ser incluído em um XObject tipo
formulário.
As seguintes chaves, se presentes em um objeto ExtGState, devem ter os valores abaixo:
 BM Normal ou Compatible
 CA 1.0
 ca 1.0
NOTA Estas provisões proíbem o uso de transparência em um arquivo conforme. O efeito visual de gráficos com
transparência parcial pode ser obtido usando técnicas que não o uso das chaves de transparência do PDF Reference,
incluindo-se dados pré-renderizados ou objetos vetoriais achatados. O uso de tais técnicas não impede o arquivo de ser
PDF/A-1.
6.5 Anotações
6.5.1 Geral
Além do comportamento de renderização definido pelo PDF Reference e modificado por esta parte da
ABNT NBR ISO 19005, leitores conformes interativos devem prover um mecanismo de visualização dos valores
das chaves Contents de dicionários de anotação.
NOTA Esta parte da ABNT NBR ISO 19005 não prescreve o comportamento ou detalhes da implementação técnica que
leitores interativos podem utilizar para implementar este requisito funcional.
6.5.2 Tipos de anotações
Os tipos de anotação não definidos no PDF Reference não devem ser permitidos. Além disso, anotações
tipo FileAttachment, Sound e Movie não devem ser permitidas.
NOTA O suporte para conteúdos multimídia está além do escopo desta parte da ABNT NBR ISO 19005.

6.5.3 Dicionário de anotação
Um dicionário de anotação não deve conter a chave CA com valor diferente de 1.0.
Um dicionário de anotação deve conter a chave F. O flag bit Print da chave F deve ter valor 1 e seus bits de flag
Hidden, Invisible e NoView devem ter valor 0.
Anotações de texto devem ter os bits de flag NoZoom e NoRotate da chave F com valor 1.
NOTA 1 As restrições nos flags das anotações previnem o uso de anotações escondidas (invisíveis) ou que são visíveis mas
não imprimíveis. Os flags NoZoom e NoRotate são aceitos, o que permite o uso de tipos de anotações que têm o mesmo
comportamento que as anotações de texto comumente usadas. Por definição, anotações de texto exibem os comportamentos
NoZoom e NoRotate mesmo quando os flags não são ajustados, como descrito em 8.4.5 do PDF Reference; o ajuste explícito
destes flags remove qualquer ambigüidade potencial entre os ajustes do annotation dictionary e o comportamento do leitor.
Um dicionário de anotação não deve conter as matrizes C ou IC, a menos que o espaço de cor do
DestOutputProfile no dicionário Outputlntent do PDF/A-1, definido em 6.2.2, seja RGB.
NOTA 2 Estas provisões asseguram que os espaços de cor tipo device usados nas anotações por mecanismos outros que
não um stream de aparência sejam indiretamente definidos pelo Outputlntent do PDF/A-1.
Se um dicionário de anotação contiver a chave AP, o dicionário de aparência que este define como seu valor deve
conter somente a chave N, cujo valor deve ser um stream que define a aparência da anotação.
NOTA 3 Todas as provisões de 6.5.3 se aplicam a todos os tipos de anotação, inclusive as de tipo Widget, utilizadas
nos campos dos formulários.
6.6 Actions
6.6.1 Geral
As ações Launch, Sound, Movie, ResetForm, ImportData e JavaScript não devem ser permitidas.
Adicionalmente, as ações obsoletas set-state e no-op também não devem ser permitidas. Ações named outras
que NextPage, PrevPage, FirstPage, e LastPage não devem ser permitidas. Em resposta a cada uma das quatro
ações named permitidas, um leitor interativo conforme deve executar a ação apropriada descrita na Tabela 8.45
do PDF Reference.
Campos interativos de formulários não devem executar nenhum tipo de ação.

NOTA 1 O suporte para conteúdo multimídia está fora do escopo desta parte da ABNT NBR ISO 19005. A ação ResetForm
muda a aparência visual de um formulário. A ação ImportData importa dados de um arquivo externo. A ação JavaScript
permite a execução de código arbitrário com o potencial de interferir com a representação visual previsível e confiável
do arquivo.
NOTA 2 Outros requisitos para campos interativos de formulários são especificados em 6.9.
6.6.2 Eventos trigger
Um dicionário de anotação Widget ou dicionário Field não deve conter a entrada AA para um dicionário additional-
actions. O dicionário catalog do documento não deve incluir uma entrada AA para um dicionário additional-actions.
NOTA Estes dicionários additional-actions definem ações arbitrárias JavaScript. A proibição explícita da entrada AA tem
o efeito implícito de não permitir ações JavaScript que possam criar dependências externas e complicar os esforços
de preservação.
6.6.3 Links de hipertexto
Leitores interativos conformes podem optar por desativar hiperlinks, mas, em adição ao comportamento de
visualização definido no PDF Reference e modificado por esta parte da ABNT NBR ISO 19005, devem prover
mecanismos para mostrar as chaves F e D de um dicionário de ação GoToR, a chave URI de um dicionário
de ação URI e a chave F de um dicionário de ação SubmitForm.

NOTA Uma vez que os hiperlinks transferem o controle da execução para fora do controle do leitor interativo, esta
subseção permite que o leitor interativo escolha se faz o hiperlink acionável ou não. Para a finalidade de evidenciar
completamente as informações armazenadas no arquivo conforme, é importante para o leitor interativo prover algum
mecanismo de exposição das destinações de todos os hiperlinks. Porém, esta parte da ABNT NBR ISO 19005 não prescreve
nenhum comportamento ou detalhe de implementação técnica de como os leitores interativos podem atender a esta subseção
de requisitos funcionais.
6.7 Metadados
6.7.1 Geral
As subseções 6.7.2 a 6.7.11 especificam os requisitos para metadados em arquivos conformes. Os metadados
são essenciais para um gerenciamento eficiente dos arquivos durante seu ciclo de vida. Um arquivo depende de
metadados para identificação e descrição, assim como para detalhamento de questões técnicas e administrativas
referentes ao arquivo. Resulta assim que os gravadores de arquivos conformes podem ter que aquiescer com
requisitos específicos ao domínio, definidos externamente a esta parte da ABNT NBR ISO 19005. Esta parte da
ABNT NBR ISO 19005 define um modelo consistente e estruturado que suporta uma ampla variedade de
requisitos de metadados.
6.7.2 Propriedades
O dicionário catalog de um arquivo conforme deve conter a chave Metadata. O stream de metadados que forma
o valor desta chave deve ser conforme a especificação XMP. Todas as propriedades dos metadados embutidas
em um arquivo devem estar no formato XMP, exceto para as entradas do dicionário de informação do documento,
que não possuam nenhuma análoga XMP, como definido em 6.7.3. As propriedades especificadas no formato
XMP devem utilizar os esquemas predefinidos na especificação 4 XMP, ou extension schemas conformes
à especificação 4 XMP e 6.7.8. Objetos dicionários de streams de metadados não devem conter a chave Filter.
NOTA 1 A proibição explícita da chave Filter tem o efeito implícito de preservar os conteúdos de streams XMP de
metadados como texto pleno e assim visível a ferramentas sem capacidade de leitura PDF.
NOTA 2 Um extension schema é um esquema XMP que não está definido na especificação XMP.
NOTA 3 De acordo com as recomendações do W3C XML Namespace[18], prefixos de namespace são atalhos para URIs de
namespace. O prefixo em si mesmo não tem um significado específico. Prefixos convencionais são utilizados nesta subseção
a título de exemplo. Excetuando-se os casos onde um determinado prefixo é identificado como requerido (em 6.7.8 e 6.7.11),
qualquer prefixo pode ser utilizado.
6.7.3 Dicionário de informação do documento
Um dicionário de informação do documento pode ocorrer em um arquivo conforme. Se não ocorrer, então todas as
suas entradas que têm propriedades análogas em esquemas XMP predefinidos, como definido na Tabela 1,
devem também ser embutidas no arquivo no formato XMP com seus valores correspondentes. Qualquer entrada
de dicionário de informação do documento não listada na Tabela 1 não deve ser embutida utilizando uma
propriedade de esquema XMP predefinida.
NOTA 1 Uma vez que um dicionário de informação do documento pode ocorrer em um arquivo conforme, é possível
[11]
a um arquivo único ser conforme a ambas as normas PDF/A-1 (ISO 19005-1) e PDF/X (ISO 15930-4 e ISO 15930-6 ).
Tabela 1 — Ligação entre o dicionário de informação do documento e as propriedades XMP
Dicionário de informação do documento XMP
Entrada Tipo PDF Propriedade Tipo XMP
Title texto string dc:title Lang Alt
Author texto string dc:creator seq ProperName
Subject texto string dc:description["x-default"] Texto
Keywords texto string pdf:Keywords Texto
Creator texto string xmp:CreatorTool AgentName
Producer texto string pdf:Producer AgentName
CreationDate data xmp:CreateDate Data
ModDate data xmp:ModifyDate Data
NOTA O URI do namespace XML para o prefixo dc é <http://purl.org/dc/elements/1.1/>; o URI do namespace para o
prefixo pdf é <http://ns.adobe.com/pdf/1.3/>; o URI do namespace para o prefixo xmp é <http://ns.adobe.com/xap/1.0/>.

O valor das entradas do dicionário de informação do documento e suas propriedades análogas XMP devem ser
equivalentes. Para as propriedades que mapeiam o tipo PDF text string para o tipo XMP Text, a equivalência
de valores deve ser de caractere a caractere, independentemente do tipo de codificação, comparando-se os
valores numéricos code points ISO/IEC 10646-1 para os caracteres.
NOTA 2 O requisito explícito de equivalência entre os valores das entradas do dicionário de informação do documento
e as propriedades XMP análogas tem o efeito implícito de prover uma interpretação não ambígua dos valores das propriedades.
Se a propriedade dc:creator estiver presente nos metadados XMP, então deve ser representada por um Text
array ordenado de comprimento um, cuja única entrada deve consistir em um ou mais nomes. A equivalência
entre Author e dc:creator deve ser de caractere a caractere, independentemente da codificação, comparando-se
os valores numéricos code points
ISO/IEC 10646-1 para os caracteres.
EXEMPLO 1 Entradas no Dicionário de informação do documento:
/Author (Peter, Paul and Mary)

são equivalentes às propriedades XMP:
<dc:creator>
<rdf:Seq>
<rdf.:li>Peter, Paul, and Mary</rdf:li>
</rdf:Seq>
</dc:creator>
As propriedades de data são formatadas com seqüência de componentes temporais de comprimento variável,
variando em granuralidade: ano, mês dia, hora, minuto, segundo. Para propriedades que mapeiam entre PDF date
type, definidas por 3.8.2 no PDF Reference, e o XMP Date type, definida por Date and Time Formats, os valores
de equivalência devem ser baseados componente por componente, relativos à UTC (Coordinated Universal Time),
por exemplo, correção da distância do horário local.
EXEMPLO 2 Entradas no Dicionário de informação do documento:
/CreationDate (D:20040402)
/ModDate (D:20040408091132-05'00')
são equivalentes às propriedades XMP:
<xmp:CreateDate>2004-04-02</xmp:CreateDate>
<xmp:ModifyDate>2004-04-08T14:11:32Z</xmp:ModifyDate>
6.7.4 Normalização
Todos os esquemas XMP devem definir as regras de normalização que são aplicáveis às suas propriedades.
Para todas as propriedades de metadados definidas nos esquemas que provêm regras de normalização,
os valores das propriedades devem entrar, ser salvos e retidos de maneira normalizada, segundo definido por
estes esquemas para facilitar o intercâmbio e suportar interpretação consistente dos metadados dos leitores
conformes.
6.7.5 Cabeçalho XMP
Os atributos bytes e encoding não devem ser usados no cabeçalho de um pacote XMP.
NOTA Ambos os atributos, bytes e encoding, ficaram obsoletos na especificação XMP.
6.7.6 Identificadores de arquivo
É recomendável que um arquivo conforme tenha uma ou mais propriedades de metadados para caracterizar,

categorizar ou identificar o arquivo. Esta parte da ABNT NBR ISO 19005 não obriga a existência de nenhum
esquema de identificação. Os identificadores podem ser baseados externamente, como o International Standard
Book Number (ISBN)[4] ou o Digital Object Identifier (DOI), ou baseados internamente como o Globally Unique
Identifier/Universally Unique Identifier (GUID/UUID), ou outra designação assinalada durante as operações de
workflow. Os identificadores podem ser incluídos através do uso das propriedades xmp:Identifier,
xmpMM:DocumentlD, xmpMM:VersionlD e xmpMM:RenditionClass; ou o uso de propriedades de um
extension schema. Qualquer sistema de identificação pode ser utilizado, desde que as propriedades sejam
conformes com os requisitos XMP e esta parte da ABNT NBR ISO 19005.
Se um arquivo conforme for modificado de qualquer maneira, mesmo somente pela adição de uma entrada
xmpMM:History, como descrito em 6.7.7, então, a parte do identificador de mudança da chave ID, no dicionário
da cauda do arquivo, deve ser modificada como descrito em 9.3 do PDF Reference.
NOTA O URI do namespace XML para o prefixo xmp é <http://ns.adobe.com/xap/1.0/>; o URI do namespace para
o prefixo xmpMM é <http://ns.adobe.com/xap/1.0/mm/>.
6.7.7 Informação de procedência do arquivo
Para descrever todas as ações de alto nível tomadas pelo usuário para criar, transformar ou instanciar um arquivo
conforme, cada ação destas deve ser registrada na propriedade xmpMM:History. Para cada ação que é gravada:
 os campos action, parameters e when devem ser especificados;
 o campo softwareAgent deve ser especificado;
 o campo instancelD não deve ser especificado.
NOTA 1 O URI do namespace XML para o prefixo xmpMM é <http://ns.adobe.com/xap/1.0/mm/>.
NOTA 2 As aplicações com requisitos específicos de auditoria podem necessitar registrar tipos adicionais de ações ou
detalhes adicionais sobre ações, além daquelas definidas nos esquemas XMP predefinidos. Exemplos de tipos adicionais de
ações incluem as que mudam a aparência do documento, como a diminuição da resolução ou a substituição de fontes.
Exemplos de detalhes adicionais incluem a identificação do agente humano que instigou ou executou a ação, ou o ambiente no
qual a ação ocorreu.
No caso onde originais em papel, microfichas ou arquivos eletrônicos são transformados em arquivos conformes,
xmpMM:History deve descrever todo o processamento de alto nível (por exemplo, transformação de PDF 1.4
para PDF/A-1); as alterações no conteúdo do arquivo ou em sua funcionalidade (por exemplo, a remoção de
código JavaScript e objetos de áudio); gerenciamento de metadados preexistentes (por exemplo, todos os valores
do dicionário de informação do documento convertido para XMP); e qualquer outro aspecto significativo dos
processos de transformação.
Para todos os arquivos conformes, criados nativamente ou pela conversão de originais, como papel, microfichas
ou outros formatos eletrônicos, xmpMM:History deve descrever todos os processos de alto nível subseqüentes
do workflow (por exemplo, descrição das atividades e handoffs); citações de políticas que governam o
gerenciamento de arquivos (por exemplo, títulos das ordens oficiais sob as quais arquivos são coletados,
processados e utilizados); nomes e versões de ferramentas de software; qualquer outro assunto que se necessitar
indicar sobre o contexto da criação e uso do arquivo.
Em casos onde as propriedades XMP de metadados foram alteradas ou apagadas, na medida em que o arquivo
se move através de seu ciclo de vida, xmpMM:History deve descrever estas alterações através da inclusão de
entradas cujos campos parameters especifiquem o nome das propriedades e seus valores prévios.
Esta recomendação se aplica a todas as propriedades de metadados, exceto a própria xmpMM:History. Se uma
propriedade de metadados tiver sido apagada, o campo action de sua entrada em xmpMM:History deve ser
pdfa.deleted.
6.7.8 Extension schemas
Todos os extension schemas usados em um arquivo conforme devem ter suas descrições embutidas no arquivo,
no stream de metadados como definido em 6.7.2. Estas descrições devem ser especificadas usando o esquema
de descrição do extension schema PDF/A, segundo especificado nesta seção.
NOTA 1 Um extension schema é um esquema XMP que não foi definido na especificação XMP Specification.

O esquema de descrição do extension schema, definido na Tabela 2, usa o URI namespace

<http://www.aiim.org/pdfa/ns/extension/>. O prefixo de namespace de schema requerido é pdfaExtension.
Tabela 2 — Esquema descritivo do extension schema do PDF/A
Propriedade Tipo de valor Categoria Descrição

pdfaExtension:schemas bag Schema Interno Contêiner para todas as descrições de
extension schema embutidas
O tipo Schema, definido na Tabela 3, é uma estrutura XMP contendo a descrição de extension schema. O campo
URI namespace é <http://www.aiim.org/pdfa/ns/schema#>. O prefixo requerido do campo namespace
é pdfaSchema.
Tabela 3 — Tipos de valores do schema PDF/A
Nome do Campo Tipo de valor Descrição

pdfaSchema: schema Texto Descrição opcional do schema
pdfaSchema:namespaceURI URI Schema namespace URI
pdfaSchema:prefix Texto Prefixo preferido de schema namespace

pdfaSchema:property seq Property Descrição das propriedades do schema
pdfaSchema:valueType seq ValueType Descrição dos tipos de valores específicos ao schema
O tipo Property, definido na Tabela 4, é uma estrutura XMP contendo a descrição de uma propriedade do schema.
O URI do campo namespace é <http://www.aiim.org/pdfa/ns/property#>. O prefixo requerido ao namespace do
campo é pdfaProperty.
Tabela 4 — Valores de tipos da Propriedade PDF/A

pdfaProperty:name Texto Nome da propriedade
pdfaProperty:valueType Escolha aberta de texto Tipo de valor da propriedade, derivada da
especificação XMP Specification 4 ou um valor
do tipo extension schema PDF/A embutido
pdfaProperty:category Escolha fechada de texto Categoria de propriedade: interna ou externa
pdfaProperty:description Texto Descrição da propriedade

Convém que os valores preferidos para a propriedade pdfaProperty:valueType sejam os tipos de valores de
propriedade, não obsoletos, definidos em XMP Specification 2004, 4. Convém que os tipos matriciais sejam
precedidos por seu tipo de conteúdo: alt, bag ou seq, separados do tipo base, por um único espaço em branco.
O tipo ValueType, definido na Tabela 5, é uma estrutura XMP contendo a descrição de todos os tipos de
propriedades de valores usados por extension schemas embutidos, que não são definidos em XMP Specification 4.
O URI namespace do campo é <http://www.aiim.org/pdfa/ns/type#>. O prefixo namespace requerido para o campo
é pdfaType.
Tabela 5 — Tipos de valor de PDF/A ValueType

pdfaType:type Texto Property value type name
pdfaType:namespace URI Property value type field namespace URI
URI

pdfaType:prefix Texto Preferred value type field namespace prefix

pdfaType:description Texto Description of the property value type
pdfaType:field seq Field Descrição opcional do campo estruturado
O tipo Field, definido na Tabela 6, é uma estrutura XMP contendo a descrição de propriedade de campo de valor.
O URI namespace do campo é <http://www.aiim.org/pdfa/ns/field#>. O prefixo namespace requerido para o campo
é pdfaField.
Tabela 6 — Tipos de valores para o Field PDF/A

pdfaField:name Texto Nome do campo
pdfaField:valueType Escolha aberta de texto Tipo de valor da propriedade, derivada da especificação
XMP Specification 4 ou um valor do tipo extension schema
PDF/A embutido
pdfaField:description Texto Descrição do campo
6.7.9 Validação
Todo o conteúdo de todos os pacotes XMP deve ser bem formado segundo definido em Extensible Markup
Language (XML) 1.0 (Third Edition), 2.1, e RDF/XML Syntax Specification (Revised), 7. Se possível, no momento
que um gravador cria ou salva novamente um arquivo conforme, todos os conteúdos dos pacotes XMP do arquivo
devem ser validados.
6.7.10 Metadados de fontes
Para todos os programas de fontes embutidos dos tipos Type 0, Type 1, ou TrueType, o dicionário do arquivo de
fonte embutido deve incluir uma entrada Metadata cujo valor é um stream de metadados XMP. Os seguintes
elementos de metadados XMP devem constar: dc:title, dando o valor da chave FontName do dicionário descritor
da fonte; dc:rights, dando a declaração de copyright; xmpRights:Marked, com o valor lógico true;
xmpRights:Owner, dando o proprietário legal da fonte; xmpRights:UsageTerms, dando uma declaração dos
termos de licença sob os quais a fonte está sendo utilizada. Metadados XMP adicionais podem ser incluídos a
critério do gravador do arquivo.
NOTA 1 Informações legais das fontes são úteis de maneira a preservar a identidade e o escopo da propriedade intelectual
do detentor de copyright daquela fonte. Enquanto muitas fontes embutem declarações de copyright e termos de licenciamento
no interior da fonte, isso não é uma prática uniforme. Portanto é vantajoso o requisito explícito da representação da declaração
de direitos em um arquivo conforme. Apesar desta prática poder ser redundante, ela deixa óbvia a necessidade para algum
sistema no futuro ter a habilidade de ler esta estrutura interna dos programas de fontes.
NOTA 2 O URI do namespace XML para o prefixo xmp é <http://ns.adobe.com/xap/1.0/>; o URI do namespace para o
prefixo xmpRights é <http://ns.adobe.com/xap/1.0/rights/>.
6.7.11 Identificação da versão e nível de conformidade
A versão PDF/A e o nível de conformidade de um arquivo devem ser especificados usando extension schema de
Identificação PDF/A definido nesta subseção.
O esquema de Identificação, definido na Tabela 7, usa o namespace URI <http://www.aiim.org/pdfa/ns/id/>.
O prefixo requerido no esquema namespace é pdfaid.
Tabela 7 — Esquema de identificação de PDF/A
Propriedade Tipo de Valor Categoria Descrição

pdfaid:part Escolha aberta de Inteiro Interno Identificador de versão do PDF/A
pdfaid:amd Escolha aberta de Texto Interno Identificador opcional de emenda do PDF/A

Pdfaid:conformance Escolha fechada de Texto Interno Nível de conformidade do PDF/A: A ou B
Recomenda-se que o valor de pdfaid:part seja o número da parte da ABNT NBR ISO 19005 ao qual o arquivo
é conforme. Se o arquivo for conforme a versão da ABNT NBR ISO 19005 que é definida por uma emenda à parte,
então o valor de pdfaid:amd deve ser o número da emenda e o ano, separados por dois pontos (:).
Um arquivo conforme o Nível A de conformidade deve especificar o valor de pdfaidconformance como A.

Um arquivo conforme o Nível B deve especificar o valor de pdfaidconformance como B.
Os valores das propriedades pdfaid:part, pdfaid:amd e pdfaid:conformance não determinam por si mesmos
a conformidade com uma parte da ABNT NBR ISO 19005. A determinação do nível de conformidade, na verdade,
será realizada segundo especificado na Seção 5.
6.8 Estrutura lógica
6.8.1 Geral
A subseção 6.8 é aplicável somente para arquivos que se encontram no Nível A de conformidade. Para o Nível B
de conformidade os requisitos de 6.8 podem ser ignorados.
O propósito dos requisitos 6.8.2 a 6.8.8 é assegurar a recuperação do conteúdo textual de arquivos conformes
como uma seqüência de palavras definidas na ordem natural de leitura da língua na qual foram escritos.
Similarmente, isso assegura que os caracteres individuais de cada palavra sejam recuperáveis na sua ordem
natural de leitura. Além disso, estes requisitos permitem a recuperação de informação semântica de alto nível
a respeito da estrutura lógica do documento.
Os gravadores de PDF/A-1 não devem adicionar informações estruturais ou semânticas que não estiverem
explícita ou implicitamente presentes no material original, devido à conformidade necessária no escopo de
arquivamento. Exemplos de tais informações são estruturas hierárquicas, especificações de linguagem natural,
descrições alternativas, anotações não textuais, textos de substituição e expansões para abreviaturas e acrônimos.
NOTA É desaconselhado que gravadores gerem informações semânticas ou estruturais utilizando processos automáticos,
sem a devida verificação.
6.8.2 PDF Tagged
6.8.2.1 Geral
Um arquivo conforme o Nível A deve atender a todos os requisitos determinados para PDF tipo Tagged, em 9.7
do PDF Reference.
NOTA O PDF Tagged define convenções para declarar e descrever explicitamente aspectos da estrutura lógica do
conteúdo do documento.
6.8.2.2 Dicionário de informação tipo Mark
O dicionário do catálogo do documento deve incluir um dicionário Marklnfo cuja única entrada, Marked, deve ter
o valor true.
NOTA Este valor indica que o arquivo é conforme às convenções do PDF Tagged.
6.8.3 Artifícios
6.8.3.1 Geral
Características de paginação como cabeçalhos ou números de página, características cosméticas de leiaute como
notas de rodapé ou figuras de fundo e recursos de produção como marcas de corte e tarjas de cor devem ser

especificadas como artifícios de paginação, leiaute de páginas, respectivamente, como descrito em 9.7.2 no PDF
Reference.
6.8.3.2 Quebras de palavras

Para linguagens e sistemas baseados em scripts que normalmente usam o caractere de espaço para indicar
quebra de palavras, as seguintes restrições devem ser aplicadas:
Dentro de comandos show strings, as quebras de palavras devem ser explicitamente indicadas pela presença de
um ou mais caracteres de espaço entre todas as palavras, individualmente, na string mostrada. Se uma palavra
terminar no final da string, um ou mais caracteres de espaço devem ser inseridos no final da show string.
Notar que uma única palavra pode se dividir em duas ou mais show strings; as quebras de palavras são indicadas
somente pela presença explícita de um ou mais caracteres de espaço, e não pelo começo ou fim de uma show
string. Com o objetivo de indicar quebra de palavras, a seqüência de um ou mais caracteres de espaço
é semanticamente equivalente a um só caractere de espaço.
6.8.3.3 Hierarquia de estrutura

A estrutura lógica de um arquivo conforme deve ser descrita por uma estrutura hierárquica com raiz na entrada
StructTreeRoot do dicionário do catálogo do documento, como descrito em 9.6 do PDF Reference.
Cada dicionário de elemento da estrutura na hierarquia de estrutura deve ter uma entrada Type com o valor de
nome StructElem.
Gravadores de arquivos conformes devem tentar capturar a estrutura lógica hierárquica do documento na sua
mais fina granularidade, lançando mão dos tipos padrão de estrutura para agrupar elementos, elementos
estruturais no nível de bloco, elementos tipo parágrafo, elementos tipo lista, elementos tipo tabela, elementos
estruturais inline-level, elementos tipo link e elementos tipo illustration, como definido em 9.7.4 do PDF Reference,
da maneira mais abrangente possível.
NOTA A descrição explícita da estrutura lógica de um documento vai provar seu valor nos futuros esforços de
recuperação do pleno valor semântico do documento com objetivo de visualização ou migração para outros formatos de dados.
6.8.3.4 Tipos estruturados

Convém que a definição de elementos de estrutura em nível de bloco siga o paradigma de forte estruturação
como descrito em 9.7.4 do PDF Reference.
Recomenda-se que todos os tipos de estruturas não padrão sejam mapeados para aqueles de funcionalidade
mais próxima entre os tipos padrão, como definido em 9.7.4 no PDF Reference, no dicionário role map da raiz da
árvore de estrutura. Este mapeamento pode ser indireto; dentro do role map, um tipo de estrutura não padrão
pode mapear diretamente para outro tipo de estrutura não padrão, mas no final o mapeamento deve terminar em
um tipo de estrutura padrão.
6.8.4 Especificação de linguagem natural
Convém que a linguagem natural padrão para todo texto de um arquivo seja especificada na entrada Lang
do dicionário do catálogo do documento.
Convém que todo o conteúdo textual dentro de um arquivo que diferir da linguagem padrão seja indicado pelo uso
da propriedade Lang anexada a uma seqüência de conteúdo marcado ou por uma entrada Lang em um dicionário
de elemento de estrutura, como descrito em 9.8.1 no PDF Reference.
Se a entrada Lang estiver presente no dicionário do catálogo do documento ou no dicionário de elemento de
estrutura ou lista de propriedades, seu valor deve ser um identificador de língua assim como definido
em RFC 1766, Tags for the Identification of Languages, assim como descrito por 9.8.1 no PDF Reference.
Toda string de texto codificada em Unicode cuja língua não for a língua natural padrão para o arquivo ou a língua
natural para o elemento mais interno da estrutura envolvente ou seqüência marked-content deve indicar sua língua
usando a seqüência de escape descrita em 3.8.1 no PDF Reference.

NOTA A distinção entre palavras estrangeiras a uma língua e palavras estrangeiras incorporadas belo uso comum em
uma língua é problemática. A intenção destes requisitos é permitir a interpretação futura não ambígua, em termos semânticos,
dos conteúdos de texto.
6.8.5 Descrições alternativas
Convém que todos os elementos tipo estrutura cujos conteúdos não tenham um análogo textual predeterminado,
por exemplo imagens, fórmulas etc. forneçam uma descrição alternativa de texto utilizando a entrada Alt no
dicionário de elemento de estrutura, como descrito em 9.8.2 no PDF Reference.
NOTA Descrições alternativas fornecem descrição textual que ajudam na interpretação adequada de conteúdos não
textuais.
6.8.6 Anotações não textuais
Para os tipos annotation que não exibem textos, convém que a chave Contents de um dicionário tipo annotation
seja especificada com uma descrição alternativa do conteúdo da anotação, um formato legível para humanos.
6.8.7 Textos substitutivos
Convém que todos os elementos de estruturas textuais que forem representados de maneira não padrão,
por exemplo caracteres customizados ou gráficos embutidos em textos, forneçam texto substitutivo usando a
entrada ActualText no de elemento de estrutura, como descrito em 9.8.3 no PDF Reference.
NOTA Texto substitutivo provê equivalentes textuais que ajudam na interpretação adequada de componentes com
representação textual incomum.
6.8.8 Expansão de abreviaturas e acrônimos
Convém que todas as instâncias de abreviaturas e acrônimos em conteúdos textuais sejam colocadas numa
seqüência marked-content com o tag Span cuja propriedade E provê uma expansão textual da abreviatura ou
acrônimo, como descrito em 9.8.4 em PDF Reference.
NOTA A expansão de abreviaturas e acrônimos provê equivalentes textuais que ajudam na interpretação adequada de
nomenclaturas que seriam, sem esta, de difícil acesso.
6.9 Formulários interativos
A intenção do requisito desta subseção é assegurar que não haja ambigüidade na representação de campos de
formulários.
Um leitor conforme jamais deve utilizar os campos de formulários para alterar a representação visual da página ou
do conteúdo do arquivo. Um dicionário de anotação Widget ou dicionário Field não deve conter as chaves A
ou AA.
Os flags Need Appearances necessários no dicionário dos formulários interativos devem estar ausentes ou estar
presentes com valor false.
Cada campo de formulário deve ter um dicionário de aparência associado com os campos de dados. Um leitor
conforme deve reproduzir o campo de acordo com o dicionário de aparência sem interferência dos dados do
formulário.
NOTA O requisito de um dicionário de aparência assegura a reprodução confiável do formulário.

Anexo A
(informativo)
PDF/A-1 – Sumário de conformidade

A.1 Geral
As informações presentes em A.1 a A.3 são fornecidas como uma maneira de se ter uma visão geral conveniente
dos objetivos da variação dos requisitos do PDF/A-1 em relação aos do PDF Reference. Porém, não é seu
propósito ser uma lista completa dos requisitos do PDF/A-1. As declarações normativas de todos os requisitos
do PDF/A-1 são encontradas nas Seções 2 a 6. No caso de qualquer discrepância entre as informações presentes
neste anexo informativo e o texto normativo, o texto normativo deve sempre ser considerado como aquele que
apresenta a declaração definitiva de todos os requisitos.
As Tabelas A.1 e A.2 listam os operadores PDF 1.4, objetos e chaves dentro de objetos para os quais
os requisitos desta parte da ABNT NBR ISO 19005 diferem do PDF Reference para a conformidade com
o PDF/A-1. Estas tabelas indicam o status do operador, objeto ou chave e a seção normativa onde este status
é definido.
Os seguintes valores são utilizados:
 Requerido O operador, objeto ou chave é requerido em arquivos conformes.
 Proibido O operador, objeto ou chave é proibido em arquivos conformes.
 Restrito O operador, objeto ou chave pode aparecer em arquivos conformes, porém somente sujeito a
limitações específicas no seu uso, valor ou conteúdo.
 Recomendado O operador, objeto ou chave deveria aparecer em arquivos conformes.
 Ignorado O operador, objeto ou chave pode aparecer em arquivos conformes, porém será ignorado por
leitores conformes.
Se forem incluídas referências a um objeto PDF dicionário em tabelas e as chaves nestes objetos não forem
listadas explicitamente, então todas as chaves nestes objetos e seus descendentes, quando houver, herdam seus
status do objeto que é mostrado na tabela. Um objeto é descendente de outro objeto, chamado de seu ancestral,
se qualquer das seguintes condições for verdadeira:
o objeto é o valor de uma chave no objeto ancestral;
o ancestral é uma matriz e o objeto é um elemento desta matriz;
o objeto é descendente de um descendente do objeto ancestral.
A.2 Operadores
Todos os operadores definidos no PDF Reference para uso em streams tipo Contents podem ser incluídos
em um arquivo conforme, sujeitos às condições mostradas na Tabela A.1.

Tabela A.1 — Status de operador
Operador Status Subseção

CS Restrito 6.2.3
cs Restrito 6.2.3
K Restrito 6.2.3
k Restrito 6.2.3
RG Restrito 6.2.3
rg Restrito 6.2.3
ri Restrito 6.2.9
Operadores não definidos no PDF Reference Proibido 6.2.10
A.3 Objetos e chaves
Todos os objetos e chaves definidos no PDF Reference podem ser incluídos em um arquivo conforme, sujeitos
às condições mostradas na Tabela A.2. Alguns dos requisitos para as chaves são relativos a pares específicos
de chaves/valores. Nestes casos o valor relevante é mostrado em seguida à chave.
Tabela A.2 — Objeto e status da chave
Objeto Chave (e valor) Status Subseção

AcroForm NeedAppearances Restrito 6.9
Action N NOP Proibido 6.6.1
S Named Restrito 6.6.1
S ImportData Proibido 6.6.1
S JavaScript
S Launch
S Movie
S ResetForm
S SetState
S Sound
Annot AA Proibido 6.6.2
CA Restrito 6.5.3
Contents Recomendado (para o Nível A de 6.8.6
conformidade de anotações não
textuais)
Subtype FileAttachment Proibido 6.5.2
Subtype Sound
Subtype Movie

Tabela A.2 (continuação)

Dicionário de propriedades de Recomendado (para o Nível A de 6.8.3
artefatos conformidade)
Catalog AA Proibido 6.6.2

Lang Recomendado (para o Nível A de 6.8.4

conformidade)
Metadata Requerido 6.7.2
Names Restrito 6.1.11
OCProperties Proibido 6.1.13
Outputlntents Restrito 6.2.2
StructTreeRoot Recomendado (para o Nível A de 6.8.3.3
conformidade)
CMap CIDSystemlnfo Restrito 6.3.3.1
WMode Restrito 6.3.3.3
ExtGState BM Restrito 6.4
CA Restrito 6.4
ca Restrito 6.4
HT Ignorado 6.2.8
SMask Restrito 6.4
TR Proibido 6.2.8
TR2 Restrito 6.2.8
Field dictionary AA Proibido 6.6.2
Filespec EF Proibido 6.1.11
Filters LZWDecode Proibido 6.1.10
Font FontDescriptor Requerido (a menos que seja Type 6.3.4
3)
ToUnicode Requerido a (para o Nível A de 6.3.8
conformidade)
Type Restrito 6.3.2
Widths Ignorado 6.3.6
Font CIDSystemlnfo Restrito 6.3.3.1
(Subtype CIDFontTypeO ou
CIDFontType2)
Font CIDtoGIDMap Restrito 6.3.3.2

(Subtype CIDFontType2)
Font Encoding Proibido (se fonte simbólica) Restrito 6.3.7

(Subtype TrueType) (se fonte não-simbólica)
Font file stream Metadata Recomendado 6.7.10

Tabela A.2 (continuação)

FontDescriptor CharSet Requerido 6.3.5
CIDSet Requerido (se CIDFont) 6.3.5
FontFile ou FontFile2 ou Requerido 6.3.5
FontFile3
Group S Restrito 6.4
Marklnfo Marked true Requerido (para o Nível A de 6.8.2.2

conformidade)
Page AA Proibido 6.6.2
PDF/A output intent dictionary DestOutputProfile Restrito 6.2.2
S Restrito 6.2.2
Span dictionary E Recomendado (para o Nível A de 6.8.8
conformidade)
Lang Recomendado (para o Nível A de 6.8.4
conformidade de conteúdos de
língua não padrão)
Stream dictionary Alternate Ignorado 6.2.3.2
F Proibido 6.1.7
FDecodeParams Proibido 6.1.7
FFilter Proibido 6.1.7
ICCBased Restrito 6.2.3.2
Structure element dictionary ActualText Recomendado (para o Nível A de 6.8.7
conformidade de elementos não
padrão)
Alt Recomendado (para o Nível A de 6.8.5
conformidade de conteúdos não
textuais)
Type StructElem Requerido (para o Nível A de 6.8.3.3
conformidade)
Trailer Encrypt Proibido 6.1.3
Trailer ID Requerido 6.1.3
XObject Subtype PS Proibido 6.2.5
XObject Group Restrito 6.4
(Subtype Form)
OPI Proibido 6.2.5
Ref Proibido 6.2.6
XObject (Subtype Image) Alternates Proibido 6.2.4
Intent Restrito 6.2.4
OPI Proibido 6.2.4
SMask Restrito 6.4
a
Existem três exceções para este status, definidas em 6.3.8.

Anexo B
(informativo)
Boas práticas para o PDF/A

B.1 Uso de metadados não-XMP

O uso de metadados não-XMP em nível de arquivo é fortemente desencorajado, pois não há como ter certeza que
estes metadados possam ser preservados de acordo com esta especificação. Nos casos onde metadados não-
XMP estiverem presentes, é preferível convertê-los para XMP, embuti-los no arquivo e descrever esta conversão
na propriedade xmpMM:History. Convém usar a propriedade xmpMM:History também para indicar qualquer
elemento não-XMP que não tenha sido convertido.
A falha na preservação de metadados pode causar problemas na localização, interpretação, gestão e autenticação
de um arquivo no futuro, o que pode diminuir ou anular seu valor de arquivo de conservação.
B.2 Identificadores de linguagens naturais

Convém que línguas sejam identificadas utilizando identificadores registrados segundo ISO 639-1[3], ISO 3166-1[5]
ou IANA[17]. Convém que o uso de identificadores privados seja feito somente se a língua usada não tiver
identificador definido nos registros de ISO 639-1, ISO 3166-1 ou IANA. No caso de uma língua ser realmente
desconhecida, o identificador x-unknown deve ser utilizado.
NOTA O uso de identificadores registrados nas ISO 639-1, ISO 3166-1 e IANA é definido em RFC 1766, Tags for
[24]
the Identification of Languages, que o PDF usa como base para seus identificadores de linguagens. A ISO 639-2 define
identificadores de linguagens com três letras que não são permitidas sob a RFC 1766.
B.3 Recomendações para captura ou conversão de documentos para PDF/A

Para o arquivamento de preservação esta declaração de boas práticas apresenta recomendações para processos
que capturam ou convertem documentos para o formato PDF/A, a fim de assegurar que os arquivos conformes
resultantes retenham suas qualidades e integridade enquanto registro. Convém que instituições de arquivamento
e outras organizações com requisitos de preservação de longo prazo sejam encorajadas a fazer uso do Nível A de
conformidade como descrito em 5.1 e as outras sugestões desta seção.
A ISO 15489-1:2001[9], 7.1, especifica que, “para suportar a continuidade da condução dos negócios, estar
conforme as regulamentações e prover informações contábeis, convém que as organizações criem e mantenham
registros, autênticos, confiáveis e usáveis, e protejam a integridade destes registros pelo tempo necessário”.
O ambiente regulatório para a submissão de documentos numa instituição de arquivamento de uma organização
pode incluir requisitos, padrões e políticas para documentos eletrônicos que estipulem regras de qualidade como
mínima resolução de imagens, restrições de compressão, ou proibir processos que alterem ou apaguem os dados
aprovados. Para o propósito de arquivamento para preservação, a qualidade e integridade dos documentos
criados de acordo com estes requisitos regulatórios e legais, padrões e políticas organizacionais aplicáveis devem
ser retidas quando são capturadas ou convertidas para PDF/A.
Para atingir esta meta necessária e crítica, os processos de captura e conversão de arquivos para PDF/A devem
replicar o exato conteúdo e qualidade do documento original no arquivo conforme. Seguem exemplos de linhas
mestras para o desenvolvimento de software a fim de atingir este escopo.

 Convém que gravadores de arquivos conformes não usarem compressão tipo lossy, subsampling,
downsampling
ou qualquer outro processo que altere o conteúdo ou degrade a qualidade da informação original no arquivo
conforme.
 Não convém que o software substitua texto pesquisável, baseado em OCR (optical character recognition),
pelo texto original escaneado na imagem bit-mapped em documentos capturados de papel ou convertidos de
imagens digitalizadas para arquivos.
NOTA O processo de OCR pode envolver perda de dados pela interpretação imprecisa dos caracteres escaneados.

Bibliografia
[1] ANSI X3.4, Information Systems — Coded Character Sets — 7-Bit American National Standard Code for
Information Interchange (7-Bit ASCII)
[2] ECMA-6, 7-Bit coded Character Set, Disponível na Internet <http://www.ecma-international.org/

publications/files/ecma-st/Ecma-Q06.pdf>
[3] ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
[4] ISO 2108, Information and documentation — International standard book number (ISBN)
[5] ISO 3166-1, Codes for the representation of names of countries and their subdivisions— Part 1: Country
codes
[6] ISO/IEC 10646-1:2000/Amd 1:2002, Amendment 1: Mathematical symbols and other characters
[7] ISO/IEC 10646-2:2001, Information technology— Universal Multiple-Octet Coded Character Set (UCS) —
Part 2: Supplementary Planes
[8] ISO/IEC 14492:2001, Information technology — Lossy/lossless coding ofbi-level images
NOTA Esta Norma Internacional é equivalente à recomendação ITU-T Recommendation T.88, Information technology —
Coded representation of picture and audio information — Lossy/lossless coding ofbi-level images
[9] ISO 15489-1:2001, Information and documentation — Records management — Part 1: General
[10] ISO/TR15801, Electronic imaging— Information stored electronically— Recommendations for

trustworthiness and reliability
[11] ISO 15930-6, Graphic technology— Prepress digital data exchange using PDF— Part 6: Complete
exchange of printing data suitable for colour-managed workflows using PDF 1.4 (PDF/X-3)
[12] ISO/TR 18492, Long-term preservation of electronic document-based information
[13] ISO 18509-1, Electronic archival storage— Specifications relative to the design and operation of information
processing systems in view of ensuring the storage and integrity on recordings stored in these systems —
Part 1: Long term access strategy
[14] ISO 18509-2, Electronic archival storage— Specifications relative to the design and operation of information
processing systems in view of ensuring the storage and integrity on recordings stored in these systems —
Part 2: Technical specifications
[15] ITU-T Recommendation T.4, Standardization of Group 3 facsimile terminals for document transmission
[16] ITU-T Recommendation T.563, Terminal characteristics for Group 4 facsimile apparatus
[17] Language Tags, IANA. Disponível na Internet <http://www.iana.org/assiqnments/lanquaqe-taqs>
[18] Namespaces in XML 1.1, W3C Recommendation, February 4, 2004. Disponível na Internet
<http://www.w3.org/TR/2004/REC-xml-names11 -20040204>
[19] PDF Reference: Adobe Portable Document Format, Version 1.5, Adobe Systems Incorporated —
4th edition. Disponível na Internet <http://partners.adobe.com/asn/acrobat/sdk/public/docs/
PDFReference15 v6.pdf>

[20] RFC 1950, ZLIB Compressed Data Format Specification version 3.3, May 1996. Disponível na Internet
<http://www.ietf.org/rfc/rfcl 950.txt>
[21] RFC 1951, DEFLATE Compressed Data Format Specification version 1.3, May 1996. Disponível na Internet
<http://www.ietf.oro/rfc/rfc1951 .txt>
[22] The Unicode Standard, Unicode Consortium. Disponível na Internet <http://www.unimde.ora/versions/>
[23] Unicode Standard Annex #15, Unicode Normalization Forms Unicode Consortium, 17 April 2003. Disponível
na Internet <httD://www.unicode.oro/unir.ode/reports/tri5/>
[24] ISO 639-2, Codes for the representation of names of languages — Part 2: Alpha-3 code

NBRISO19005-1 - Arquivo para Impressão

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

NBRISO19005-1 - Arquivo para Impressão

Enviado por

Direitos autorais:

Formatos disponíveis

Documento impresso em 31/03/2020 19:46:47, de uso exclusivo de INST. FED. DE EDUC., CIÊNC. E TECN.

NORMA ABNT NBR

Gerenciamento de documentos — Formato

Palavras-chave: Gerenciamento de documentos. Documento eletrônico. PDF 1.4.

ICS 35.240.30; 37.100.99

© ISO 2005 - © ABNT 2009

ABNT NBR ISO 19005-1:2009

ii © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

ABNT NBR ISO 19005-1:2009

2 Referências normativas ................................................................................................................................1

© ISO 2005 - © ABNT 2009 - Todos os direitos reservados iii

ABNT NBR ISO 19005-1:2009

 Parte 1: Uso PDF 1.4 (PDF/A-1)

O Escopo desta Norma Brasileira em inglês é o seguinte:

 specific technical design, user interface, implementation, or operation details of rendering;

 required computer hardware and/or operating systems.

iv © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

ABNT NBR ISO 19005-1:2009

 requisitos de retenção do ambiente de arquivamento de longo prazo da organização, políticas de records

 quaisquer outros requisitos e condições necessárias para assegurar a persistência de documentos,

© ISO 2005 - © ABNT 2009 - Todos os direitos reservados v

ABNT NBR ISO 19005-1:2009

 ISO/TR 15801, [10];

 ISO/TR 18492, [12];

 ISO 18509-1, [13];

 ISO 18509-2, [14];

 “PDF/A” – um sinônimo para a família ISO 19005;

 “PDF/A-1” – um sinônimo para a ISO 19005-1;

 “PDF/A-1a” – um sinônimo para a ISO 19005-1 Nível de conformidade A;

 “PDF/A-1b” – um sinônimo para a ISO 19005-1 Nível de conformidade B.

vi © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

NORMA BRASILEIRA ABNT NBR ISO 19005-1:2009

Gerenciamento de documentos — Formato eletrônico de arquivo de

Esta parte da ABNT NBR ISO 19005 não se aplica a:

 processos específicos para conversão de papel ou documentos eletrônicos no formato PDF/A;

 projeto técnico específico, interfaces de usuário, implementações ou detalhes operacionais de representação;

 requisitos de hardware, software e/ou sistemas operacionais de computadores.

ISO/IEC 9541-1, Information technology — Font information interchange — Part 1: Architeture

© ISO 2005 - © ABNT 2009 - Todos os direitos reservados 1

ABNT NBR ISO 19005-1:2009

XMP Specification, novembro de 2003 (em preparação), Adobe Systems Incorporated

Para os efeitos deste documento, aplicam-se os seguintes termos e definições.

2 © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

ABNT NBR ISO 19005-1:2009

© ISO 2005 - © ABNT 2009 - Todos os direitos reservados 3

ABNT NBR ISO 19005-1:2009

EXEMPLO O valor Default da chave TR2.

EXEMPLO CARRIAGE RETURN (0Dh).

EXEMPLO EN SPACE (U+2002).

4 © ISO 2005 - © ABNT 2009 - Todos os direitos reservados

ABNT NBR ISO 19005-1:2009

5.2 Nível de conformidade A

5.3 Nível de conformidade B

5.4 Leitores conformes

6.1 Estrutura de arquivo

O caractere % do cabeçalho do arquivo deve ocorrer no byte de offset 0, no arquivo.

© ISO 2005 - © ABNT 2009 - Todos os direitos reservados 5

ABNT NBR ISO 19005-1:2009

6.1.3 File trailer

6.1.4 Cross reference table

6.1.5 Document information dictionary

6.1.6 Objetos tipo string

Strings hexadecimais devem conter um número ímpar de caracteres espaços-não-brancos, cada um de 0 a 9, A