traduccion

Contenidos Página
Prólogo vi
Introducción vii
1 Alcance 1
2 Conformidad 1
2.1 En general 1
2.2 Lectores conformes 1
2.3 Escritores conformes 1
2.4 Productos conformes 2
3 Referencias normativas 2
4 Términos y definiciones 6
5 Notación 10
6 Designaciones de versions 10
7 Sintaxis 11
7.1 General 11
7.2 Convenciones léxicas 11
7.3 Objetos 13
7.4 Filtros 22
7.5 Estructura de archives 38
7.6 Cifrado 55
7.7 Estructura de documentos 70
7.8 Corrientes de contenido y recursos 81
7.9 Estructuras de datos communes 84
7.10 Funciones 92
7.11 Especificaciones de archivo 99
7.12 Diccionario de extensions 108
8 Gráficos 110
8.1 General 110
8.2 Objetos gráficos 110
8.3 Sistemas de coordenadas 114
8.4 Estado de gráficos 121
8.5 Construcción y pintura de ruta 131
8.6 Espacios de color 138
8.7 Patrones 173
8.8 Objetos externos 201
8.9 Imágenes 203
8.10 Objetos de formularios X 217
8.11 Contenido opcional 222
9 Texto 237
9.1 En general 237
92 Organización y uso de Fuentes 237
9.3 Parámetros de estado de texto y operators 243
9.4 Objetos de texto 248
9.5 Introducción a las estructuras de datos de Fuentes 253
9.6 Fuentes simples 254
9.7 Fuentes compuestas 267
9.8 Descriptores de Fuentes 281
9.9 Programas de fuentes incrustadas 288
9.10 Extracción de contenido de texto 292
10 Renderizado 296
10.1 General 296
10.2 Color a base de CIE al color del dispositivo 297
10.3 Conversiones entre los espacios de color del dispositivo 297
10.4 Funciones de transferencia 300
10.5 Semitonos 301
10.6 Escanear los detalles de conversion 316
11 Transparencia 320
11.1 General 320
11.2 Resumen de la transparencia 320
11.3 Cálculos básicos de composición 322
11.4 Grupos de transparencia 332
11.5 Máscaras suaves 342
11.6 Especificando la transparencia en PDF 344
11.7 Espacio de color y temas de representación 353
12 Características interactivas 362
12.1 General 362
12.2 Preferencias del espectador 362
12.3 Navegación a nivel de documentos 365
12.4 Navegación a nivel de página 374
12.5 Anotaciones 381
12.6 Acciones 414
12.7 Formas interactivas 430
12.8 Firmas digitales 466
12.9 Propiedades de medición 479
12.10 Requisitos de documentos 484
13 Características multimedia 486
13.1 General 486
13.2 Multimedia 486
13.3 Sonidos 506
13.4 Películas 507
13.5 Presentaciones alternativas 509
13.6 Obra 3D 511
14 Intercambio de documentos 547
14.1 General 547
14.2 Conjuntos de procedimientos 547
14.3 Metadatos 548
14.4 Identificadores de archivo 551
14.5 Los diccionarios de la pieza de página 551
14.6 Contenido marcado 552
14.7 Estructura lógica 556
14.8 Etiquetado PDF 573
14.9 Soporte de accesibilidad 610
14.10 Captura Web 616
14.11 Soporte de preimpresion 627
Anexo A
(informativo)
Resumen del operador 643
Anexo B
(normativo)
Operadores en funciones tipo 4 647
Anexo C
(normativo)
Límites de implementación. 649
Anexo D
(normativo)
Conjuntos de personajes y codificaciones 651
Anexo E
(normativo)
Registro de nombre PDF 673
Anexo F
(normativo)
PDF linealizado 675
Anexo G
(informativo)
Estrategias de acceso de PDF linealizadas 695
Anexo H
(informativo)
Ejemplo de archivos PDF 699
Anexo I
(normativo)
Versiones PDF y Compatibilidad 727
Anexo J
(informativo)
PDF Ejemplo de Implementación de Cambio de Nombre de Bandera 729
Anexo K
(informativo)
Compatibilidad PostScript - Modelo de imágenes transparente 731
Anexo L
(informativo)
Placas de color 733
Bibliografía 745
Prólogo
El 29 de enero de 2007, Adobe Systems Incorporated anunció la intención de lanzar el

formato de documento portátil completo (PDF) 1.7 Especificaciones del Instituto
Nacional Nacional de American (ANSI) y la Asociación de Administración de
Contenidos Enterpriseros (AIIM). para Propósito de la publicación por la
Organización Internacional de Normalización (ISO).
PDF se ha convertido en una norma global de facto para un intercambio de

información más seguro y confiable, ya que Adobe publicó la especificación completa
de PDF en 1993. Ambos gobernables Tanto el gobierno como la industria privada han
llegado a confiar en el PDF para los volúmenes de registros electrónicos que deben ser
compartidos, gestionados y, en algunos casos, preservados de manera más segura y
confiable durante generaciones. Desde 1995, Adobe ha participado en varios grupos
de trabajo que desarrollan especificaciones técnicas para su publicación por la ISO y
ha trabajado dentro del proceso de la ISO para entregar subconjuntos especializados
del PDF como estándares para industrias y funciones específicas. Hoy en día, el PDF
para Archivo (PDF/A) y el PDF para Intercambio (PDF/X) son estándares ISO, y el
PDF para Ingeniería (PDF/E) y el PDF para Acceso Universal (PDF/UA) son
estándares propuestos. Además, el PDF para Atención Médica (PDF/H) es una Guía
de Mejores Prácticas propuesta por AIIM. AIIM actúa como el administrador del
PDF/A, PDF/E, PDF/UA y PDF/H.
En la primavera de 2008, el documento ISO 32000 fue preparado por Adobe Systems
Incorporated (basado en la Referencia PDF, sexta edición, versión 1.7 del Formato de
Documento Portátil de Adobe, noviembre de 2006) y fue revisado, editado y
adoptado, bajo un "procedimiento acelerado", por el Comité Técnico ISO/TC 171,
Aplicación de gestión documental, Subcomité SC 2, Problemas de aplicación, en
paralelo con su aprobación por los organismos miembros de ISO.
En enero de 2008, este comité técnico de ISO aprobó la documentación revisada final
para el PDF 1.7 como el estándar internacional ISO 32000-1. En julio de 2008, el
documento ISO fue puesto a la venta en el sitio web de ISO (http://www.iso.org).
Este documento que está leyendo ahora es una copia del estándar ISO 32000-1. Según
el acuerdo con ISO, se permite a Adobe Systems ofrecer esta versión del estándar ISO
como un archivo PDF gratuito en su sitio web. No es un documento oficial de ISO,
pero el contenido técnico es idéntico, incluyendo la numeración de secciones y la
numeración de páginas.
Introducción
La ISO 32000 especifica una forma digital para representar documentos llamada
Formato de Documento Portátil o comúnmente referida como PDF. El PDF fue
desarrollado y especificado por Adobe Systems Incorporated a partir de 1993 y
continuó hasta 2007, cuando se preparó este estándar ISO. La versión de Adobe
Systems del PDF 1.7 es la base de esta edición de ISO 32000. Las especificaciones del
PDF son inclusivas hacia atrás, lo que significa que el PDF 1.7 incluye toda la
funcionalidad documentada previamente en las Especificaciones PDF de Adobe para
las versiones 1.0 a 1.6. Cabe señalar que donde Adobe eliminó ciertas características
del PDF de su estándar, tampoco están contenidas aquí.
El objetivo del PDF es permitir a los usuarios intercambiar y ver documentos
electrónicos de manera fácil y confiable, independiente del entorno en el que fueron
creados o del entorno en el que se visualizan o imprimen. En el núcleo del PDF hay un
modelo de imágenes avanzado derivado del lenguaje de descripción de página
PostScript. Este Modelo de Imágenes PDF permite la descripción de texto y gráficos
de manera independiente del dispositivo y sin depender de la resolución. Para mejorar
el rendimiento de la visualización interactiva, el PDF define un formato más
estructurado que el utilizado por la mayoría de los programas del lenguaje PostScript.
A diferencia de PostScript, que es un lenguaje de programación, el PDF se basa en un
formato de archivo binario estructurado que está optimizado para un alto rendimiento
en la visualización interactiva. El PDF también incluye objetos, como anotaciones y
enlaces de hipertexto, que no son parte del contenido de la página en sí, pero son útiles
para la visualización interactiva y el intercambio de documentos.
Los archivos PDF pueden ser creados de manera nativa en formato PDF, convertidos
de otros formatos electrónicos o digitalizados a partir de papel, microforma u otro
formato de copia impresa. Empresas, gobiernos, bibliotecas, archivos y otras
instituciones e individuos de todo el mundo utilizan el PDF para representar cuerpos
considerables de información importante.
En los últimos catorce años, apoyado por el crecimiento explosivo de Internet, el PDF
se ha utilizado ampliamente para el intercambio electrónico de documentos. Existen
varias aplicaciones específicas del PDF que han evolucionado, donde limitar el uso de
algunas características del PDF y requerir el uso de otras aumenta la utilidad del PDF.
La ISO 32000 es un estándar ISO para el PDF de función completa; los siguientes
estándares son para usos más especializados. PDF/X (ISO 15930) es ahora el estándar
de la industria para la representación intermedia de materiales impresos en sistemas de
preimpresión electrónicos para aplicaciones de impresión convencional. PDF/IA (ISO
19005) es ahora el estándar de la industria para el archivado de documentos digitales.
PDF/IE (ISO 24517) proporciona un mecanismo para representar documentos de
ingeniería y el intercambio de datos de ingeniería. A medida que grandes
corporaciones, agencias gubernamentales e instituciones educativas optimizan sus
operaciones al reemplazar el flujo de trabajo basado en papel con el intercambio
electrónico de información, el impacto y la oportunidad de la aplicación del PDF
seguirán creciendo a un ritmo rápido.
El PDF, junto con software para crear, visualizar, imprimir y procesar archivos PDF
de diversas maneras, cumple un conjunto de requisitos para documentos electrónicos
que incluye:
 preservación de la fidelidad del documento independiente del dispositivo,
plataforma y software,
 fusión de contenido de diversas fuentes: sitios web, programas de
procesamiento de texto y hojas de cálculo, documentos escaneados, fotos y
gráficos, en un solo documento autosuficiente, manteniendo la integridad de
todos los documentos originales,
 edición colaborativa de documentos desde múltiples ubicaciones o
plataformas,
 firmas digitales para certificar autenticidad,
 seguridad y permisos que permiten al creador retener el control del
documento y los derechos asociados,
 accesibilidad del contenido para personas con discapacidades,
 extracción y reutilización de contenido para su uso con otros formatos de
archivo y aplicaciones, y
 formularios electrónicos para recopilar datos e integrarlos con sistemas
empresariales.
La Organización Internacional de Normalización llama la atención sobre el hecho de
que se alega que el cumplimiento de este documento puede implicar el uso de patentes
relacionadas con la creación, modificación, visualización y procesamiento de archivos
PDF que son propiedad de las siguientes partes:
 Adobe Systems Incorporated, 345 Park Avenue, San José, California, 95110-
2704, EE. UU.
ISO no toma posición respecto a la evidencia, validez y alcance de estos derechos de
patente. Los titulares de estos derechos de patente han asegurado a la ISO que están
dispuestos a negociar licencias en términos y condiciones razonables y no
discriminatorios con solicitantes de todo el mundo. En este sentido, las declaraciones
de los titulares de estos derechos de patente están registradas ante la ISO. Se puede
obtener información de las partes mencionadas anteriormente.
Se llama la atención sobre la posibilidad de que algunos de los elementos de este
documento puedan estar sujetos a derechos de patente distintos de los identificados
anteriormente. ISO no será responsable de identificar ninguno de esos derechos de
patente.
Se ha establecido un repositorio de documentos referenciados por AIIM
(http://www.aiim.org/pdfrefdocs). No todos los documentos referenciados se pueden
encontrar allí debido a restricciones de derechos de autor.
Gestión de documentos - Formato de documento portátil –
Parte 1:
PDF 1.7
IMPORTANTE — El archivo electrónico de este documento contiene colores que
se consideran útiles para la correcta comprensión del documento. Por lo tanto,
los usuarios deben considerar imprimir este documento utilizando una impresora
a color.
1 Alcance
Esta Norma Internacional especifica una forma digital para representar documentos
electrónicos para permitir a los usuarios intercambiar y visualizar documentos
electrónicos independiente del entorno en el que fueron creados o del entorno en el
que se visualizan o imprimen. Está destinada al desarrollador de software que crea
archivos PDF (escritores conformes), software que lee archivos PDF existentes e
interpreta su contenido para su visualización e interacción (lectores conformes) y
productos PDF que leen y/o escriben archivos PDF para una variedad de otros
propósitos (productos conformes).
Esta norma no especifica lo siguiente:
 procesos específicos para convertir documentos en papel o electrónicos al
formato PDF;
 diseño técnico específico, interfaz de usuario o detalles de implementación u
operacionales de la representación;
 métodos físicos específicos de almacenamiento de estos documentos, como
medios y condiciones de almacenamiento;
 métodos para validar la conformidad de archivos PDF o lectores;
 hardware de computadora y/o sistema operativo requeridos.
2 Conformidad
2.1 General
Los archivos PDF conformes deberán cumplir con todos los requisitos de la
especificación ISO 32000-1, y un archivo conforme no está obligado a usar ninguna
característica más allá de las explícitamente requeridas por la ISO 32000-1.
NOTA 1: El mecanismo adecuado por el cual un archivo puede presumiblemente
identificarse como un archivo PDF de un determinado nivel de versión se describe en
7.52, "Encabezado de archivo".
2.2 Lectores conformes
Un lector conforme deberá cumplir con todos los requisitos relacionados con el
comportamiento funcional del lector especificados en la ISO 32000-1. Los requisitos
de la ISO 32000-1 con respecto al comportamiento del lector se expresan en términos
de requisitos funcionales generales aplicables a todos los lectores conformes. La ISO
32000-1 no prescribe ningún diseño técnico específico, interfaz de usuario o detalles
de implementación de lectores conformes. La representación de archivos conformes
deberá realizarse como se define en la ISO 32000-1.
2.3 Escritores conformes
Un escritor conforme deberá cumplir con todos los requisitos relacionados con la
creación de archivos PDF según lo especificado en la ISO 32000-1. Los requisitos de
la ISO 32000-1 con respecto al comportamiento del escritor se expresan en términos
de requisitos funcionales generales aplicables a todos los escritores conformes y se
centran en la creación de archivos conformes. La ISO 32000-1 no prescribe ningún
diseño técnico específico, interfaz de usuario o detalles de implementación de
escritores conformes.
2.4 Productos conformes
Un producto conforme deberá cumplir con todos los requisitos relacionados con la
creación de archivos PDF según lo especificado en la ISO 32000-1, así como cumplir
con todos los requisitos relacionados con el comportamiento funcional del lector
especificados en la ISO 32000-1.
3 Referencias normativas
Los siguientes documentos de referencia son indispensables para la aplicación de este
documento. Para referencias datadas, sólo se aplica la edición citada. Para referencias
no datadas, se aplica la última edición del documento de referencia (incluidas
cualquier enmienda).
ISO 639-1:2002, Códigos para la representación de nombres de lenguas — Parte 1:
código alfa-2.
ISO 639-2:1998. Códigos para la representación de nombres de lenguas — Parte 2:
código alfa-3.
ISO 3166-1:2006, Códigos para la representación de nombres de países y sus
subdivisiones — Parte 1: códigos de país.
ISO 3166-2:1998. Códigos para la representación de nombres de países y sus
subdivisiones — Parte 2: código de subdivisión del país.
ISO/IEC 8824-1:2002, Notación de Sintaxis Abstracta Uno (ASN.1): Especificación
de notación básica.
ISO/IEC 10918-1:1994. Compresión Digital y Codificación de Imágenes Still de Tono
Continuo (conocido informalmente como el estándar JPEG, del Grupo de Expertos
Fotográficos Conjuntos, el grupo ISO que desarrolló el estándar).
ISO/IEC 15444-2:2004, Tecnología de la Información—Sistema de Codificación de
Imágenes JPEG 2000: Extensiones.
ISO/IEC 11544:1993/Cor 22001. Tecnología de la información—Representación
codificada de información visual y de audio—Compresión progresiva de imágenes de
dos niveles (JBIG2).
IEC/3WD 61966-2.1 : 1999, Medición y Gestión del Color en Sistemas y Equipos
Multimedia, Parte 2.1: Espacio de Color RGB Predeterminado—sRGB.
ISO 15076-1:2005. Gestión del color en tecnología de imagen - Arquitectura, formato
de perfil y estructura de datos Parte 1 Basado en ICC. 1:2004-10.
ISO 10646:2003, Tecnología de la información — Conjunto de Caracteres
Codificados Universales de Múltiples Octetos (UCS).
ISO/IEC 9541-1:1991. Tecnología de la información Intercambio de información de
fuentes Parte 1: Arquitectura.
ANSI Sistemas de Información - Conjuntos Codificados 7-Bit Código Nacional
Americano Estándar para el Intercambio de Información (ASCII de 7 bits).
NOTA 1 Los siguientes documentos se pueden encontrar en Al1M en
(http://www.aiim.org/pdfrefdocs) así como en el sitio web de Adobe Systems
Incorporated http://www.adobe.com/go/pdf_ref_bibliography.
PDF Reference, Versión 1.7, - 5ª ed. (ISBN 0-321-30474-8). Adobe Systems
Incorporated.
JavaScript para Acrobat API Reference, Versión 8.0, (abril de 2007), Adobe Systems
Incorporated.
Referencia de JavaScript para Acrobat 3D, (abril de 2007), Adobe Systems
Incorporated.
Lista de Glifos de Adobe. Versión 2.0, (septiembre de 2002). Adobe Systems
Incorporated.
OPI: Especificación de Interfaz Abierta de Preimpresión 1.3, (septiembre de 1993).
Adobe Systems Incorporated.
Especificación del Diccionario de Construcción de Firmas PDF v. 1.4, (marzo de
2008), Adobe Systems Incorporated.
Arquitectura XML de Adobe, Especificación de Arquitectura de Formularios (XFA),
versión 2.5, (junio de 2007), Adobe Systems Incorporated.
versión 2.4, (septiembre de 2006), Adobe Systems Incorporated.
versión 2.2, (junio de 2005), Adobe Systems Incorporated.
versión 2.0, (octubre de 2003), Adobe Systems Incorporated.
NOTA 2 A partir de XFA 2.2, la especificación XFA incluye la Especificación de
Plantilla, la Especificación de Configuración, la Especificación XDP, y todas las
demás especificaciones XML únicas para la Arquitectura de Formularios XML
(XFA).
Arquitectura XML de Adobe, Especificación del Paquete de Datos XML (XDP),
versión 2.0, (octubre de 2003), Adobe Systems Incorporated.
Arquitectura XML de Adobe, Especificación de Plantilla, versión 2.0, (octubre de
2003), Adobe Systems Incorporated.
Especificación del Formato de Datos de Formularios XML, versión 2.0, (septiembre
de 2007), Adobe Systems Incorporated.
XMP: Plataforma de Metadatos Extensible, (septiembre de 2005), Adobe Systems
Incorporated.
TIFF Revisión 6.0, Final, (junio de 1992), Adobe Systems Incorporated.
NOTA 3 Las siguientes Notas Técnicas se pueden encontrar en el sitio web de Al1M
http://www.aiim.org/pdfnotes así como en el sitio web de Adobe Systems
Incorporated (htpp://www.adobe.com) utilizando la función de búsqueda general,
ingresando el número de la Nota Técnica.
Nota Técnica #5004, Especificación del Formato de Archivo de Métricas de Fuentes
de Adobe, Versión 4.1, (octubre de 1998), Adobe Systems Incorporated.
NOTA 4 Los archivos de métricas de fuentes de Adobe (AFM) están disponibles a
través de la sección de Tipos del sitio web de AS N.
Nota Técnica #5014, Especificación de Archivos de Fuentes CMap y CID de Adobe,
Versión 1.0, (junio de 1993), Adobe Systems Incorporated.
Nota Técnica #5015, Suplemento de Formato de Fuente Tipo 1, (mayo de 1994),
Nota Técnica #5078, Colección de Caracteres Adobe-Japan1-4 para Fuentes con
Clave CID, (junio de 2004), Adobe Systems Incorporated.
Nota Técnica #5079, Colección de Caracteres Adobe-GB1-4 para Fuentes con Clave
CID, (noviembre de 2000), Adobe Systems Incorporated.
Nota Técnica #5080, Colección de Caracteres Adobe-CNS1-4 para Fuentes con Clave
CID, (mayo de 2003), Adobe Systems Incorporated.
Nota Técnica #5087, Programas de Fuentes de Múltiples Maestros para Macintosh,
(febrero de 1992), Adobe Systems Incorporated.
Nota Técnica #5088, Problemas de Nomenclatura de Fuentes, (abril de 1993), Adobe
Systems Incorporated.
Nota Técnica #5092, Visión General de la Tecnología de Fuentes Clave CID,
(septiembre de 1994), Adobe Systems Incorporated.
Nota técnica #5093. Colección de caracteres Adobe-Korea1-2 para fuentes con clave
Nota técnica #5094. Colecciones de caracteres CJKV de Adobe y CMaps para fuentes
con clave CID, (junio de 2004), Adobe Systems Incorporated.
Nota técnica #5097. Colección de caracteres Adobe-Japan2-0 para fuentes con clave
Nota técnica #5116. Compatibilidad con filtros DCT en PostScript Nivel 2,

(noviembre de 1992), Adobe Systems Incorporated.
Nota técnica #5176. Especificación del formato de fuente compacta (Compact Font
Format Specification), versión 1.0, (diciembre de 2003), Adobe Systems Incorporated.
Nota técnica #5177. El formato de cadenas de caracteres tipo 2 (Type 2 Charstring

Format), (diciembre de 2003), Adobe Systems Incorporated.
Nota técnica #5411. Tutorial sobre archivos de mapeo ToUnicode, (mayo de 2003),
Nota técnica #5620. Formato de ticket de trabajo portátil (Portable Job Ticket
Format), versión 1.1, (abril de 1999), Adobe Systems Incorporated.
Nota técnica #5660. Interfaz de preimpresión abierta (Open Prepress Interface),
especificación versión 2.0, (enero de 2000), Adobe Systems Incorporated.
NOTA 5: Los siguientes documentos están disponibles como publicaciones de

estándares federales de procesamiento de información:
 FIPS PUB 186-2, Digital Signature Standard (Estándar de firma digital),

describe las firmas DSA, (enero de 2000), Federal Information Processing
Standards.
 FIPS PUB 197, Advanced Encryption Standard (AES) (Estándar de
encriptación avanzada), (noviembre de 2001), Federal Information Processing
Standards.
NOTA 6: Los siguientes documentos están disponibles como RFCs del Internet
Engineering Task Force (IETF):
RFC 1321, El algoritmo MD5 para resumen de mensajes, (abril de 1992), Grupo
de trabajo de ingenieria por internet IETF.
RFC 1738, Localizadores uniformes de recursos (URLs), (diciembre de 1994),

Grupo de trabajo de ingenieria por internet IETF.
RFC 1808, Localizadores uniformes de recursos relativos (Relative URLs), (junio

de 1995), Grupo de trabajo de ingenieria por internet IETF.
RFC 1950, Especificación del formato de datos comprimidos ZLIB, versión 3.3,
(mayo de 1996), Grupo de trabajo de ingenieria por internet IETF.
RFC 1951, Especificación del formato de datos comprimidos DEFLATE, versión

1.3, (mayo de 1996), Grupo de trabajo de ingenieria por internet IETF.
RFC 2045 y 2046, Extensiones multipropósito de correo de Internet (MIME),

Partes 1 y 2: Cuerpos y tipos de medios, (noviembre de 1996), Grupo de trabajo de
ingenieria por internet IETF.
RFC 2083, Especificación PNG (Portable Network Graphics), versión 1.0, (marzo
RFC 2315, PKCS #7: Sintaxis de mensajes criptográficos, versión 1.5, (marzo de
1998), Grupo de trabajo de ingenieria por internet IETF.
RFC 2396, Identificadores uniformes de recursos (URI): Sintaxis genérica, (agosto

RFC 2560, Protocolo de estado de certificados en infraestructura de clave pública
en Internet (OCSP), (junio de 1999), Grupo de trabajo de ingenieria por internet
IETF.
RFC 2616, Protocolo de transferencia de hipertexto—HTTP/1.1, (junio de 1999),

Grupo de trabajo de ingenieria por internet IETF.
RFC 2898, PKCS #5: Especificación de criptografía basada en contraseñas,

versión 2.0, (septiembre de 2000), Grupo de trabajo de ingenieria por internet
IETF.
RFC 3066, Etiquetas para la identificación de idiomas, (enero de 2001), Grupo de

trabajo de ingenieria por internet IETF.
RFC 3161, Protocolo de marcas de tiempo para infraestructura de clave pública

X.509 en Internet, (agosto de 2001), Grupo de trabajo de ingenieria por internet
IETF.
RFC 3174, Algoritmo de resumen seguro de EE. UU. 1 (SHA-1), (septiembre de

2001), Grupo de trabajo de ingenieria por internet IETF.
RFC 3280, Infraestructura de clave pública X.509 en Internet: Perfil de

certificados y listas de revocación, (abril de 2002), Grupo de trabajo de ingenieria
por internet IETF.
NOTA 7: Los siguientes documentos están disponibles de otras fuentes:
Formato de fuente Adobe Type 1, Versión 1.1, (Febrero de 1993), Addison-Wesley,

ISBN 0-201-57044-0.
Especificación de fuente Tipo abierto 1.4, (Diciembre de 2004), Microsoft.
Manual de referencia Tipo verdadero, (Diciembre de 2002), Apple Computer, Inc.
Estándar ECMA-363, Formato de archivo 3D universal, 1ª Edición (U3D),

(Diciembre de 2004), Ecma International.
Guía de métricas de clasificación PANOSE, (Febrero de 1997), Hewlett-Packard

Corporation.
Registro de datos de caracterización ICC, Consorcio Internacional del Color
(ICC).
Recomendaciones T.4 y T.6, Codificación de fax de Grupo 3 y Grupo 4, Unión
Internacional de Telecomunicaciones (UIT).
Especificación técnica de archivos de fuente Tipo verdadero 1.0, Microsoft
Corporation.
Referencia de JavaScript del lado del cliente, (Mayo de 1999), Fundación Mozilla.
El estándar Unicode, Versión 4.0, Addison-Wesley, Boston, MA, 2003, Consorcio

Unicode.
Anexos del estándar Unicode: #9 (Algoritmo bidireccional), #14 (Propiedades de

salto de línea) y #29 (Límites de texto), varias fechas, Consorcio Unicode.
Lenguaje de marcado extensible (XML) 1.1, Consorcio World Wide Web (W3C).
4. Términos y definiciones
Para los propósitos de este documento, se aplican los siguientes términos y
definiciones.
4.1(elipsis)
Una elipsis se utiliza dentro de los ejemplos PDF para indicar detalles omitidos. Los
pares de elipsis también se utilizan para delimitar comentarios, en cursiva, sobre tales
detalles omitidos.
4.2 Valor de 8 bits (ver byte)
4.3 Objeto array: una colección unidimensional de objetos dispuestos

secuencialmente y numerados implícitamente comenzando desde 0.
4.4 ASCII: el Código Estándar Americano para el Intercambio de Información, una

convención ampliamente utilizada para codificar un conjunto específico de 128
caracteres como números binarios definidos en ANSI.
4.5 Datos binarios: una secuencia ordenada de bytes.
4.6 Objetos booleanos: ya sea la palabra clave verdadero o la palabra clave false.
4.7 Byte: un grupo de 8 dígitos binarios que en conjunto puede configurarse para
representar uno de 256 valores diferentes; diversas realizaciones de los 8 dígitos
binarios son ampliamente utilizadas en el equipo electrónico actual.
4.8 Catálogo: el objeto diccionario primario que contiene referencias directa o
indirectamente a todos los demás objetos en el documento, con la excepción de que
puede haber objetos en el tráiler que no están referidos por el catálogo.
4.9 Símbolo: código numérico que representa un símbolo abstracto de acuerdo con
alguna regla de codificación de caracteres definida.
NOTA 1 Hay tres manifestaciones de caracteres en PDF, dependiendo del contexto:
 Un archivo PDF se representa como una secuencia de bytes de 8 bits, algunos

de los cuales se interpretan como códigos de caracteres en el conjunto de
caracteres ASCII y algunos de los cuales se tratan como datos binarios
arbitrarios dependiendo del contexto.
 El contenido (datos) de un objeto de cadena o flujo en algunos contextos se
interpreta como códigos de caracteres en el conjunto de caracteres
PDFDocEncoding o UTF-16.
 El contenido de una cadena dentro de un flujo de contenido PDF en algunas
situaciones se interpreta como códigos de caracteres que seleccionan glifos que
deben ser dibujados en la página de acuerdo a una codificación de caracteres
asociada con la fuente de texto.
4.10 Conjunto de caracteres: un conjunto definido de símbolos, cada uno asignado a

un valor de carácter único.
4.11 Lector conforme: aplicación de software que es capaz de leer y procesar

archivos PDF que han sido creados conforme a esta especificación y que a sí misma
cumple con los requisitos de los lectores conformes especificados aquí [ISO 32000-1].
4.12 Producto conforme: aplicación de software que es tanto un lector conforme

como un escritor conforme.
4.13 Escritor conforme: aplicación de software que puede escribir archivos PDF que
son conformes a esta especificación [ISO 32000-1].
4.14 Flujo de contenido: objeto de flujo cuyo contenido consiste en una secuencia de
instrucciones describiendo los elementos gráficos que deben pintarse en una página.
4.15 Tabla de referencias cruzadas: estructura de datos que contiene el

desplazamiento en bytes de inicio para cada uno de los objetos indirectos dentro del
archivo.
4.16 Desarrollador: cualquier entidad, incluidas personas, empresas, organizaciones
sin fines de lucro, cuerpos de estándares, grupos de código abierto, etc., que esté
desarrollando estándares o software para usar y extender la ISO 32000-1.
4.17 Objeto diccionario: una tabla asociativa que contiene pares de objetos, donde el
primer objeto es un objeto nombre que sirve como clave y el segundo objeto sirve
como valor, y puede ser de cualquier tipo de objeto, incluyendo otro diccionario.
4.18 Objeto directo: cualquier objeto que no ha sido convertido en un objeto

indirecto.
4.19 Documento electrónico: representación electrónica de una agregación orientada

a páginas de datos de texto, imagen y gráfico, y metadatos útiles para identificar,
comprender y representar esos datos, que pueden ser reproducidos en papel o
mostrados sin pérdida significativa de su contenido informativo.
4.20 Marcador de fin de línea (EOL): secuencia de uno o dos caracteres que marca
el final de una línea de texto, consistente en un carácter de RETORNO DE CARRO
(0Dh) o un carácter de SALTO DE LÍNEA (0Ah) o un RETORNO DE CARRO
seguido inmediatamente por un SALTO DE LÍNEA.
4.21 Archivo PDF: archivo que conforma al Formato de Datos de Formularios que
contiene datos de formularios o anotaciones que pueden ser importados a un archivo
PDF (ver 127.7, "Formato de Datos de Formularios").
4.22 Filtro: una parte opcional de la especificación de un objeto de flujo, indicando

cómo se deben decodificar los datos en el flujo antes de ser utilizados.
4.23 Fuente: colección identificada de gráficos que pueden ser glifos u otros
elementos gráficos [ISO 15930-41].
4.24 Función: un tipo especial de objeto que representa clases parametrizadas,

incluyendo fórmulas matemáticas y representaciones muestreadas con resolución
arbitraria.
4.25 Glifo: símbolo gráfico abstracto reconocible que es independiente de cualquier

diseño específico [ISO/IEC 9541-1].
4.26 Estado gráfico: la parte superior de una pila de parámetros de control gráfico
que definen el marco global actual en el que se ejecutan los operadores gráficos.
4.27 Perfil ICC: perfil de color conforme a la especificación ICC [ISO 15076-
1:2005].
4.28 Objeto indirecto: un objeto que está etiquetado con un número de objeto entero
positivo seguido por un número de generación no negativo seguido de "obj" y
teniendo "endobj" después de él.
4.29 Objeto entero: enteros matemáticos con un intervalo especificado por una
implementación centrada en 0 y escritos como uno o más dígitos decimales,
opcionalmente precedidos por un signo.
4.30 Objeto nombre: símbolo atómico definido de manera única por una secuencia
de caracteres introducida por un SOLIDO (/), (2Fh), pero el SOLIDO no se considera
parte del nombre.
4.31 Árbol de nombres: similar a un diccionario que asocia claves y valores, pero las
claves en un árbol de nombres son cadenas y están ordenadas.
4.32 Objeto nulo: un único objeto de tipo nulo, denotado por la palabra clave null, y
que tiene un tipo y valor que no son iguales a los de ningún otro objeto.
4.33 Árbol de números: similar a un diccionario que asocia claves y valores, pero las
claves en un árbol de números son enteros y están ordenadas.
4.34 Objeto numérico: ya sea un objeto entero o un objeto real.
4.35 Objeto: una estructura de datos básica de la cual se construyen archivos PDF, e
incluye estos tipos: array, booleano, diccionario, entero, nombre, nulo, real, flujo y
cadena.
4.36 Referencia de objeto: valor de objeto utilizado para permitir que un objeto se
refiera a otro; que tiene la forma <número> <m> R donde <número> es un número de
objeto indirecto, <m> es su número de versión y R es la letra mayúscula R.
4.37 Flujo de objetos: un flujo que contiene una secuencia de objetos PDF.
4.38 PDF: formato de archivo del Formato de Documento Portátil definido por esta
especificación [ISO 32000-1].
4.39 Objeto real: números matemáticos reales aproximados, pero con rango y
precisión limitados, escritos como uno o más dígitos decimales con un signo opcional
y un punto seguido, anterior o incrustado (2Eh) (punto decimal).
4.40 Rectángulo: objeto array específico que se usa para describir ubicaciones en una
página y cajas delimitadoras para una variedad de objetos, escrito como un array de
cuatro números que dan las coordenadas de un par de esquinas opuestas
diagonalmente, típicamente en la forma [llx lly urx ury] especificando las coordenadas
x e y del inferior izquierdo, y x e y del superior derecho del rectángulo, en ese orden.
4.41 Diccionario de recursos: asocia nombres de recursos, utilizados en flujos de

contenido, con los propios objetos de recursos y organizados en varias categorías (por
ejemplo, Fuente, Espacio de Color, Patrón).
4.42 Carácter de espacio: carácter de cadena de texto utilizado para representar

espacio en blanco ortográfico en cadenas de texto.
NOTA 2 Los caracteres de espacio incluyen TABULACIÓN HORIZONTAL

(U+0009), SALTO DE LÍNEA (U+000A), TABULACIÓN VERTICAL (U+000B),
SALTO DE PÁGINA (U+000C), RETORNO DE CARRO (U+000D), ESPACIO
(U+0020), ESPACIO SIN RUPTURA (U+00A0), ESPACIO EN ANCHO (U+2002),
ESPACIO EN EM (U+2003), ESPACIO FIGURADO (U+2007), ESPACIO DE
PUNTUACIÓN (U+2008), ESPACIO DELGADO (U+2009), ESPACIO MUY
DELGADO (U+200A), ESPACIO SIN ANCHO (U+200B) y ESPACIO
IDEOGRÁFICO (U+3000).
4.43 Objeto de flujo: consiste en un diccionario seguido por cero o más bytes
encerrados entre las palabras clave stream y endstream.
4.44 Objeto de cadena: consiste en una serie de bytes (valores enteros sin signo en el
rango de 0 a 255) y los bytes no son objetos enteros, sino que se almacenan en una
forma más compacta.
4.45 Captura de web: se refiere al proceso de crear contenido PDF mediante la

importación y posiblemente la conversión de archivos basados en Internet o archivos
residenciales localmente. Los archivos que se importan pueden ser de cualquier
formato arbitrario, como HTML, GIF, JPEG, texto y PDF.
4.46 Carácter de espacio en blanco: caracteres que separan construcciones

sintácticas PDF, como nombres y números entre sí; los caracteres de espacio en
blanco son TABULACIÓN HORIZONTAL (09h), SALTO DE LÍNEA (0Ah),
SALTO DE PÁGINA (0Ch), RETORNO DE CARRO (0Dh), ESPACIO (20h) (ver
Tabla 1 en 7.22, "Conjunto de caracteres").
4.47 Archivo XFDF: archivo que conforma al Especificación del Formato de Datos
de Formularios XML 2.0, que es una transliteración XML del Formato de Datos de
Formularios (FDF).
4.48 Paquete XMP: envoltura estructurada para metadatos XML serializados que
pueden ser incrustados en una amplia variedad de formatos de archivo.
5 Notación
Los operadores PDF, las palabras clave de PDF, los nombres de las claves en los
diccionarios PDF y otros nombres predefinidos se escriben en una fuente sans serif en
negrita; las palabras que denotan los operandos de los operadores PDF o los valores de
las claves de los diccionarios se escriben en una fuente sans serif en cursiva.
Los caracteres de token utilizados para delimitar objetos y describir la estructura de

los archivos PDF, como se define en 7.2, "Convenciones Léxicas", pueden
identificarse por su nombre de carácter en mayúsculas en fuente sans serif en negrita
seguido de un valor hexadecimal de dos dígitos entre parenthesis “h”.
Los caracteres en los flujos de texto, como se define en 7.9.2, "Tipos de Objetos de
Cadena", pueden identificarse por su nombre de carácter en mayúsculas en fuente sans
serif seguido de un valor hexadecimal de cuatro dígitos entre paréntesis con un prefijo
“U+”, como se muestra en el EJEMPLO 1 de esta cláusula.
EJEMPLO 1: Espacio (U+2002).
6 Designaciones de Versión
Para la conveniencia del lector, las versiones de PDF en las que se introdujeron varias
características se proporcionan informativamente dentro de este documento. La
primera versión de PDF se designó PDF 1.0 y fue especificada por Adobe Systems
Incorporated en el documento PDF Reference 1.0 publicado por Adobe y Addison
Wesley. Desde entonces, PDF ha pasado por siete revisiones designadas como: PDF
1.1, PDF 1.2, PDF 1.3, PDF 1.4, PDF 1.5, PDF 1.6 y PDF 1.7. Todas las
características no obsoletas definidas en una versión anterior de PDF también fueron
incluidas en la versión posterior de PDF. Dado que ISO 32000-1 es una versión de
PDF que coincide con PDF 1.7, también es adecuada para la interpretación de
archivos realizados de conformidad con cualquiera de las especificaciones de PDF 1.0
a 1.7. A lo largo de esta especificación, para indicar en qué punto de la secuencia de
versiones se introdujo una función, se utiliza una notación con un número de versión
PDF entre paréntesis (por ejemplo, (PDF 1.3)). Así, si una función está etiquetada con
(PDF 1.3), significa que PDF 1.0, PDF 1.1 y PDF 1.2 no estaban especificados para
admitir esta función, mientras que todas las versiones de PDF 1.3 en adelante estaban
definidas para admitirla.
7 Sintaxis
7.1 General
Esta cláusula cubre todo lo relacionado con la sintaxis de PDF a nivel de objeto,
archivo y documento. Prepara el escenario para las cláusulas siguientes, que describen
cómo se interpretan los contenidos de un archivo PDF como descripciones de página,
ayudas de navegación interactivas y estructuras lógicas a nivel de aplicación.
La sintaxis PDF se entiende mejor considerándola como cuatro partes, como se

muestra en la Figura 1:
 Objetos. Un documento PDF es una estructura de datos compuesta por un

pequeño conjunto de tipos básicos de objetos de datos. La subcláusula 7.2,
"Convenciones Léxicas," describe el conjunto de caracteres utilizados para
escribir objetos y otros elementos sintácticos. La subcláusula 7.3, "Objetos,"
describe la sintaxis y las propiedades esenciales de los objetos. La subcláusula
7.3.8, "Objetos de Flujo," proporciona detalles completos del tipo de datos más
complejo, el objeto de flujo.
 Estructura de archivo. La estructura del archivo PDF determina cómo se

almacenan los objetos en un archivo PDF, cómo se accede a ellos y cómo se
actualizan. Esta estructura es independiente de la semántica de los objetos. La
subcláusula 7.5, "Estructura del Archivo," describe la estructura del archivo. La
subcláusula 7.6, "Cifrado," describe un mecanismo a nivel de archivo para
proteger el contenido de un documento contra accesos no autorizados.
 Estructura del documento. La estructura del documento PDF especifica cómo se

utilizan los tipos básicos de objeto para representar componentes de un
documento PDF: páginas, fuentes, anotaciones, etc. La subcláusula 7.7,
"Estructura del Documento," describe la estructura general del documento; las
cláusulas posteriores abordan la semántica detallada de los componentes.
 Flujos de contenido. Un flujo de contenido PDF contiene una secuencia de

instrucciones que describen la apariencia de una página u otra entidad gráfica.
Estas instrucciones, aunque también se representan como objetos, son
conceptualmente distintas de los objetos que representan la estructura del
documento y se describen por separado. La subcláusula 7.8, "Flujos de
Contenido y Recursos," discute los flujos de contenido PDF y sus recursos
asociados.
Objetos
Estructura de archivos
Estructura de documentos
Flujo de contenido
Figura 1- Componentes PDF
Además, esta cláusula describe algunas estructuras de datos, construidas a partir de

objetos básicos, que son tan ampliamente utilizadas que casi se pueden considerar
tipos de objeto básicos por derecho propio. Estos objetos se tratan en: 7.9, "Estructuras
de Datos Comunes"; 7.10, "Funciones"; y 7.11, "Especificaciones de Archivos."
NOTA: Las variantes de la sintaxis de objeto y archivo de PDF también se utilizan

como base para otros formatos de archivo. Estos incluyen el Formato de Datos de
Formularios (FDF), descrito en 127.7, "Formato de Datos de Formularios," y el
Formato de Tiquetes de Trabajo Portátil (PJTF), descrito en la Nota Técnica de Adobe
#5620, Formato de Tiquetes de Trabajo Portátil.
7.2 Convenciones Léxicas
7.2.1 General
A nivel más fundamental, un archivo PDF es una secuencia de bytes. Estos bytes
pueden agruparse en tokens de acuerdo con las reglas de sintaxis descritas en esta
subcláusula. Uno o más tokens se combinan para formar entidades sintácticas de nivel
superior, principalmente objetos, que son los valores de datos básicos a partir de los
cuales se construye un documento PDF.
Un PDF no cifrado puede representarse completamente utilizando valores de byte

correspondientes al subconjunto de caracteres imprimibles visibles del conjunto de
caracteres definido en ANSI, más caracteres de espacio en blanco. Sin embargo, un
archivo PDF no está restringido al conjunto de caracteres ASCII; puede contener bytes
arbitrarios, sujeto a las siguientes consideraciones:
 Los tokens que delimitan objetos y que describen la estructura de un archivo

PDF deben utilizar el conjunto de caracteres ASCII. Además, todas las palabras
reservadas y los nombres utilizados como claves en los diccionarios estándar de
PDF, y ciertos tipos de arreglos, deben definirse utilizando el conjunto de
caracteres ASCII.
 Los valores de datos de los objetos de cadenas y flujos pueden escribirse ya sea
completamente utilizando el conjunto de caracteres ASCII o completamente en
datos binarios. En la práctica, los datos que son naturalmente binarios, como
imágenes muestreadas, se representan generalmente en binario por compacidad
y eficiencia.
 Un archivo PDF que contiene datos binarios se transportará como un archivo
binario y no como un archivo de texto para asegurar que todos los bytes del
archivo se conserven fielmente.
NOTA 1: Un archivo binario no debe estar sujeto a entornos que impongan códigos de
carácter reservados, longitudes máximas de línea, convenciones de fin de línea u otras
restricciones.
NOTA 2: En esta cláusula, el uso del término carácter es completamente

independiente de cualquier significado lógico que el valor pueda tener cuando se trate
como datos en contextos específicos, como representar texto legible por humanos o
seleccionar un glifo de una fuente.
7.2.2 Conjunto de Caracteres
El conjunto de caracteres PDF se divide en tres clases: caracteres regulares,

delimitadores y caracteres de espacio en blanco. Esta clasificación determina la
agrupación de caracteres en tokens. Las reglas definidas en esta subcláusula se aplican
a todos los caracteres en el archivo, excepto dentro de cadenas, flujos y comentarios.
Los caracteres de espacio en blanco que se muestran en la Tabla 1 separan las

construcciones sintácticas, como nombres y números, entre sí. Todos los caracteres de
espacio en blanco son equivalentes, excepto en comentarios, cadenas y flujos. En
todos los demás contextos, PDF trata cualquier secuencia de caracteres de espacio en
blanco consecutivos como un único carácter.
Tabla 1 — Caracteres de espacio en blanco
Decimal Hexadecimal Octal Nombre

0 00 000 Nulo (NUL)
9 09 011 PESTAÑA HORIZONTAL (HT)
10 0A 012 SALTO DE LINEA (LF)
12 0C 014 FORMA DE LINEA (FF)
13 0D 015 RETORNO DE CARRO (CR)
32 20 040 ESPACIO (SP)
Los caracteres de RETORNO DE CARRO (0Dh) y SALTO DE LINEA (0Ah),

también llamados caracteres de nueva línea, se tratarán como marcadores de fin de
línea (EOL). La combinación de un RETORNO DE CARRO seguido inmediatamente
de un SALTO DE LINEA se tratará como un único marcador EOL. Los marcadores
EOL pueden tratarse de la misma manera que cualquier otro carácter de espacio en
blanco. Sin embargo, a veces se requiere o se recomienda un marcador EOL, es decir,
que preceda a un token que debe aparecer al comienzo de una línea.
NOTA: Los ejemplos en este estándar utilizan una convención que organiza los tokens
en líneas. Sin embargo, el uso de espacios en blanco para la indentación en los
ejemplos es puramente por claridad de exposición y no es necesario incluirlo en el uso
práctico.
Los caracteres delimitadores (, ), <, >, [ ,]{, }, /, y %) son especiales (PARENTESIS

IZQUIERDO (28h), PARENTESIS DERECHO (29h), SIGNO MENOR QUE (3Ch),
SIGNO MAYOR QUE (3Eh), CORCHETE IZQUIERDO (5Bh), CORCHETE
DERECHO (5Dh), LLAVE IZQUIERDA (7Bh), LLAVE DERECHA (7Dh),
SOLIDO (2Fh) y SIGNO DE PORCENTAJE (25h)). Delimitan entidades sintácticas
como arreglos, nombres y comentarios. Cualquiera de estos caracteres termina la
entidad que lo precede y no está incluido en la entidad. Se permiten caracteres
delimitadores dentro del alcance de una cadena cuando siguen las reglas para
componer cadenas; ver 7.3.4.2, "Cadenas Literales". El paréntesis de apertura ( de una
cadena delimita una entidad precedente y el paréntesis de cierre ) de una cadena
delimita el final de la cadena.
Tabla 2 — Caracteres Delimitadores
Glifo Decimal Hexadecimal Octal Nombre

( 40 28 50 Paréntesis izquierda
) 41 29 51 Paréntesis derecho
< 60 60 Signo menor que
> 62 Signo mayor que
[ 91 133 Corchete izquierdo
] 93 135 Corchete derecho
{ 123 173 llave izquierda
} 125 175 llave derecha
/ 47 57 Solido
% 37 25 45 Signo de porcentaje
Todos los caracteres, excepto los caracteres de espacio en blanco y los delimitadores,
se refieren como caracteres regulares. Estos caracteres incluyen bytes que están fuera
del conjunto de caracteres ASCII. Una secuencia de caracteres regulares consecutivos
constituye un único token. PDF distingue entre mayúsculas y minúsculas; las letras
mayúsculas y minúsculas correspondientes se considerarán distintas.
7.2.3 Comentarios
Cualquier aparición del SIGNO DE PORCENTAJE (25h) fuera de una cadena o flujo
introduce un comentario. El comentario consiste en todos los caracteres después del
SIGNO DE PORCENTAJE y hasta, pero sin incluir, el final de la línea, incluidos
caracteres regulares, delimitadores, ESPACIO (20h) y PESTAÑA HORIZONTAL
(09h). Un lector conforme ignorará los comentarios y los tratará como un único
carácter de espacio en blanco. Es decir, un comentario separa el token que lo precede
del que lo sigue.
EJEMPLO: El fragmento PDF en este ejemplo es sintácticamente equivalente a solo

los tokens abc y 123.
ABC% comentario (ho) bla bla bla123
Los comentarios (excepto los comentarios %PDF—n.m y %%EOF descritos en 7.5,

"Estructura del Archivo") no tienen semántica. No necesariamente son preservados
por aplicaciones que editan archivos PDF.
7.3 Objetos
7.3.1 General
PDF incluye ocho tipos básicos de objetos: valores booleanos, números enteros y
reales, cadenas, nombres, arreglos, diccionarios, flujos, y el objeto nulo.
Los objetos pueden tener etiqueta para que puedan ser referenciados por otros. Un
objeto etiquetado se llama un objeto indirecto (ver 7.3.10, "Objetos Indirectos").
Cada tipo de objeto, su método de creación y su correcta referencia como objetos

indirectos se describe en 7.3.2, "Objetos Booleanos" hasta 7.3.10, "Objetos
Indirectos."
7.3.2 Objetos Booleanos
Los objetos booleanos representan los valores lógicos verdadero y falso. Aparecen en
los archivos PDF utilizando las palabras clave verdadero y falso.
7.3.3 Objetos Numéricos
PDF proporciona dos tipos de objetos numéricos: enteros y reales. Los objetos enteros
representan enteros matemáticos. Los objetos reales representan números reales
matemáticos. El rango y la precisión de los números pueden estar limitados por las
representaciones internas utilizadas en el ordenador en el que se está ejecutando el
lector conforme; el Anexo C proporciona estos límites para las implementaciones
típicas.
Un número entero se escribirá como uno o más dígitos decimales, opcionalmente
precedidos por un signo. El valor se interpretará como un entero decimal con signo y
se convertirá en un objeto entero.
EJEMPLO 1: Objetos enteros

123 43445 +17 -98 0
Un valor real se escribirá como uno o más dígitos decimales con un signo opcional y
un PUNTO (2Eh) (punto decimal) que puede estar al principio, al final o incrustado.
El valor se interpretará como un número real y se convertirá en un objeto real.
EJEMPLO 2: Objetos reales
34.5 -3.62 +123.6 4. -.002 0.0
NOTA 1 Un escritor conforme no deberá utilizar la sintaxis de PostScript para
números con bases no decimales (como 16#FFFE) o en formato exponencial (como
6.02E23).
NOTA 2 A lo largo de este estándar, el término número se refiere a un objeto cuyo

tipo puede ser ya sea entero o real. Siempre que se espere un número real, se puede
utilizar un entero en su lugar. Por ejemplo, no es necesario escribir el número 1.0 en
formato real; el entero 1 es suficiente.
7.3.4 Objetos de Cadena
7.3.4.1 General
Un objeto de cadena consistirá en una serie de cero o más bytes. Los objetos de
cadena no son objetos enteros, sino que se almacenan en un formato más compacto.
La longitud de una cadena puede estar sujeta a límites de implementación; consulte el
Anexo C.
Los objetos de cadena se escribirán de una de las siguientes dos maneras:
 Como una secuencia de caracteres literales encerrados en paréntesis () (usando

PARÉNTESIS IZQUIERDO (28h) y PARÉNTESIS DERECHO (29h));
consulte 7.3.4.2, "Cadenas Literales."
 Como datos hexadecimales encerrados en corchetes angulares <> (usando
SIGNO MENOR QUE (3Ch) y SIGNO MAYOR QUE (3Eh)); consulte 7.3.4.3,
"Cadenas Hexadecimales."
NOTA En muchos contextos, existen para la interpretación del contenido de un valor

de cadena. Esta subcláusula define solo la sintaxis básica para escribir una cadena
como una secuencia de bytes; las convenciones o reglas que rigen el contenido de las
cadenas en contextos particulares se describen con la definición de esos contextos
particulares. La sección 7.9.2, "Tipos de Objetos de Cadena," describe los esquemas
de codificación utilizados para el contenido de los objetos de cadena.
7.3.4.2 Cadenas Literales
Una cadena literal se escribirá como un número arbitrario de caracteres encerrados en

paréntesis. Cualquier carácter puede aparecer en una cadena, excepto paréntesis
desbalanceados (PARÉNTESIS IZQUIERDO (28h) y PARÉNTESIS DERECHO
(29h)) y la barra invertida (SOLIDO INVERSO (5Ch)), que se tratarán de manera
especial, como se describe en esta subcláusula. Los pares de paréntesis balanceados
dentro de una cadena no requieren tratamiento especial.
EJEMPLO 1: Las siguientes son cadenas literales válidas:
Las siguientes son cadenas literales válidas:

(Esta es una cadena)
(Las cadenas pueden contener saltos de línea y demás.)
(Las cadenas pueden contener paréntesis balanceados ( ) y caracteres especiales ( *!
&)%y otros).)
(Lo siguiente es una cadena vacía.)
()
(Tiene longitud cero (O).)
Dentro de una cadena literal, el SOLIDO INVERSO se usa como un carácter de

escape. El carácter inmediatamente siguiente al SOLIDO INVERSO determina su
interpretación precisa, como se muestra en la Tabla 3. Si el carácter siguiente al
SOLIDO INVERSO no es uno de los que se muestran en la Tabla 3, el SOLIDO
INVERSO se ignorará.
Tabla 3 — Secuencias de escape en cadenas literales:

Secuencia Significado
\n SALTO DE LÍNEA (OAh) (LF)
\r RETORNO DE CARRERA (ODh) (CR)
\t TABULACIÓN HORIZONTAL (09h) (HT)
\b RETROCESO (08h) (BS)
\f SALTO DE PÁGINA (0Ch) (FF)
$ PARÉNTESIS IZQUIERDO (28h)
$ PARÉNTESIS DERECHO (29h)
\\ SOLIDO INVERSO (5Ch) (barra invertida)
\ddd Código de carácter ddd (octal)
Un escritor conforme puede dividir una cadena literal en varias líneas. El SOLIDO
INVERSO (5Ch) (carácter barra invertida) al final de una línea se usará para indicar
que la cadena continúa en la siguiente línea. Un lector conforme deberá ignorar el
INVERSO
Ejemplo 2 (Estos Dos

cuerdas son lo
mismo )
(Estas dos cuerdas son lo mismo. )
Un marcador de extremo de línea que aparece dentro de una cadena literal sin un
SOLIDO INVERSO precedente se tratará como un valor de byte de (OAH).
Independientemente de si el marcador de final de línea fue un RETORNO DE
CARRO (ODH), una FUENTE DE LINEA (OAH), o ambos.
Ejemplo 3 (Esta cadena tiene un final de línea al final de él. (Entonces, este, uno)
La secuencia I, la secuencia de escape DDD proporciona una manera de representar

caracteres fuera del conjunto de caracteres ASCII imprimible.
Ejemplo 4 (Esta cadena contiene \ 245dos Caracteres Octales \ 307. )
El número DDD puede consistir en uno, dos o tres dígitos octales: el desbordamiento
de orden alto se ignorará. Se utilizarán tres dígitos octales, con ceros principales según
sea necesario. Si el siguiente carácter de la cadena también es un dígito.
Ejemplo 5 el literal
(\00053)
denota una cadena que contiene dos caracteres, 005 (control-e)
seguido del dígito 3. mientras que ambos
(\0053)
y
(\053)
Denote las cadenas que contienen el único carácter \ 053, un signo más
Dado que el valor de 8 bits puede aparecer en una cadena (con la escapada adecuada
para el sólido inversa (barra posterior) y los paréntesis desequilibrados) esta notación \
ddd proporciona una manera de especificar caracteres fuera del conjunto de caracteres
ASCII solo usando caracteres ASCII solamente. Sin embargo,Cualquier valor de 8
bits puede aparecer en una cadena, representado como en sí mismo o con la notación \
DDD descrita.
Cuando se cifra un documento (ver 7.6 ". Cifrado"), todas sus cadenas están
encriptadas; Los valores de cadena cifrada contienen valores arbitrarios de 8 bits. Al
escribir cadenzas cifradas utilizando la forma de cadena literal, el escritor conforme
seguirá las reglas descritas. Eso es El carácter de sólido inverso se utilizará como un
escape para especificar paréntesis desequilibrados o el propio carácter de solido
inverso. El sólido inverso puede. pero no es necesario. Para ser utilizado para
especificar otros valores arbitrarios de 8 bits.
7.3.4.3 Cuerdas hexadecimales
Las cadenas también se pueden escribir en forma hexadecimal, que es útil para incluir
datos binarios arbitrarios en un archivo PDF. Un hexadecimaLa cadena L se debe
escribir como una secuencia de dígitos hexadecimales (0-9 y o A-F) codificados como
caracteres ASCII y se encierra dentro de los soportes de ángulo (usando SIGNO
MENOR QUE (3CH) y SIGNO MAYOR QUE (3EH)).
Ejemplo 1 < 4E6F762073686D6F7A206B6120706F702E>
Cada par de dígitos hexadecimales define un byte de la cadena. Los caracteres de
espacio en blanco (como el ESPACIO (20H), LA PERTAÑA HORIZONTAL (09H),
EL RETORNO DE CARRO (ODH), EL SALTO DE LINEA (OOH) y LA
ALIMENTACION DEL FORMULARIO (OCH)) se ignorarán.
Si falta el dígito final de una cadena hexadecimal, eso es. Si hay un número
extrañoBer of Digits: se supondrá el dígito final para ser O.
Ejemplo 2
<901FA3>
es una cadena de 3 bytes que consiste en los caracteres cuyos códigos
hexadecimales son 90, 1 F y A3, pero
<901FA>
es una cadena de 3 bytes que contiene los caracteres cuyos códigos
hexadecimales son 90. Si lo. y ao.
7.3.5 Objetos de nombre

A partir de PDF 1.2 Un objeto de nombre es un símbolo atómico definido de manera
única por una secuencia de cualquier carácter (valores de 8 bits), excepto NULL
(código de caracteres O). Definitivamente definido significa que cualquier objeto de
dos nombres compuesto por la misma secuencia de characTers denotan el mismo
objeto. Atómico significa que un nombre no tiene una estructura interna; Aunque se
define por una secuencia de caracteres, esos caracteres no se consideran elementos del
nombre.
Al escribir un nombre en un archivo PDF, un SOLIDO (2FH) (\) se utilizara para
intriducir un nombre. El SOLIDO no es parte del nombre, sino que es un prefijo que
indica que lo que sigue es una secuencia de caracteres que representan el nombre en el
archivo PDF y seguirá estas reglas:
a) Un SIGNO DE NÚMERO (23h) (#) en un nombre deberá escribirse utilizando su
código hexadecimal de 2 dígitos (23), precedido por el SIGNO DE NÚMERO.
b) Cualquier carácter en un nombre que sea un carácter regular (distinto del SIGNO
DE NÚMERO) deberá escribirse tal cual o utilizando su código hexadecimal de 2
dígitos, precedido por el SIGNO DE NÚMERO.
c) Cualquier carácter que no sea un carácter regular deberá escribirse utilizando su

código hexadecimal de 2 dígitos, precedido solo por el SIGNO DE NÚMERO.
NOTA 1: No existe una codificación única de los nombres en un archivo PDF porque
los caracteres regulares pueden ser codificados de dos maneras.
El espacio en blanco utilizado como parte de un nombre deberá siempre codificarse

utilizando la notación hexadecimal de 2 dígitos y no podrá haber espacio en blanco
entre el SOLIDUS y el nombre codificado.
Los caracteres regulares que estén fuera del rango del SIGNO DE EXCLAMACIÓN
(21h) (!) al TILDE (7Eh) (—) deberán escribirse utilizando la notación hexadecimal.
El token SOLIDO (una barra seguida de ningún carácter regular) introduce un nombre
único y válido definido por la secuencia vacía de caracteres.
NOTA 2: Los ejemplos mostrados en la Tabla 4 y que contienen el carácter # no son

nombres literales válidos en PDF 1.0 o 1.1.
Tabla 4 — Ejemplos de nombres literales:

Sintaxis del nombre literal Nombre resultante
/Name1 Name 1
/ASomewhatLongerName ASomewhatLongerName
/A;Name_With-Various***Characters? A;Name_With-Various***Characters?
/1.2 1.2
/$$ $$
/@pattern @pattern
/.notdef . notdef
/Lime#20Green Lime Green
/paired#28#29parentheses paired()parentheses
/The_Key_of_F#23_Minor The_Key_of_F#23_Minor
/A#42 AB
En PDF, los nombres literales siempre serán introducidos por el carácter SOLIDOS, a
diferencia de palabras clave como true, false y obj.
NOTA 3: Este estándar sigue una convención tipográfica de escribir los nombres sin
el SOLIDOS inicial cuando aparecen en texto continuo y en tablas. Por ejemplo, Type
y FullScreen denotan nombres que realmente serían escritos en un archivo PDF (y en
los ejemplos de código de este estándar) como /Type y /FullScreen.
La longitud de un nombre estará sujeta a un límite de implementación; ver Anexo C.

El límite se aplica al número de caracteres en la representación interna del nombre.
Por ejemplo, el nombre /A#20B tiene tres caracteres (A, ESPACIO, B), no seis.
Como se mencionó antes, los objetos nombre se tratarán como atómicos dentro de un
archivo PDF. Normalmente, los bytes que componen el nombre nunca se tratarán
como texto para ser presentado a un usuario humano o a una aplicación externa a un
lector conforme. Sin embargo, ocasionalmente puede surgir la necesidad de tratar un
objeto nombre como texto, como uno que represente un nombre de fuente (ver la
entrada BaseFont en la Tabla 111), un nombre de colorante en un espacio de color
separación o DeviceN, o un tipo de estructura (ver 14.7.3. "Tipos de Estructura").
En tales situaciones, la secuencia de bytes (después de la expansión de las secuencias

SIGNO DE NÚMERO, si las hay) debería interpretarse según UTF-8, una
representación de longitud variable de Unicode codificada en bytes en la que los
caracteres ASCII imprimibles tienen las mismas representaciones que en ASCII. Esto
permite que un objeto nombre represente texto virtualmente en cualquier idioma
natural, sujeto al límite de implementación sobre la longitud de un nombre.
NOTA 4: PDF no prescribe qué secuencia UTF-8 elegir para representar cualquier
pieza de texto especificado externamente como un objeto nombre. En algunos casos,
pueden existir múltiples secuencias UTF-8 que representen el mismo texto lógico. Los
objetos nombre definidos por diferentes secuencias de bytes constituyen objetos
nombre distintos en PDF, aunque las secuencias UTF-8 puedan tener interpretaciones
externas idénticas.
7.3.6 Objetos de Arreglo
Un objeto arreglo es una colección unidimensional de objetos dispuestos

secuencialmente. A diferencia de los arreglos en muchos otros lenguajes de
programación, los arreglos de PDF pueden ser heterogéneos; es decir, los elementos
de un arreglo pueden ser cualquier combinación de números, cadenas, diccionarios o
cualquier otro objeto, incluidos otros arreglos. Un arreglo puede tener cero elementos.
Un arreglo deberá escribirse como una secuencia de objetos encerrados en
CORCHETES (usando el CORCHETE IZQUIERDO (5Bh) y el CORCHETE
DERECHO (5Dh)).
EJEMPLO:
[549 3.14 false (Ralph) 1SomeName]
PDF solo admite arreglos unidimensionales de forma directa. Los arreglos de

dimensiones superiores pueden construirse utilizando arreglos como elementos de
arreglos, anidados a cualquier profundidad.
7.3.7 Objetos de Diccionario
Un objeto diccionario es una tabla asociativa que contiene pares de objetos, conocidos
como las entradas del diccionario. El primer elemento de cada entrada es la clave y el
segundo elemento es el valor. La clave debe ser un nombre (a diferencia de las claves
de diccionario en PostScript, que pueden ser objetos de cualquier tipo). El valor puede
ser cualquier tipo de objeto, incluido otro diccionario. Una entrada de diccionario
cuyo valor sea null (ver 7.3.9, "Objeto Nulo") se tratará igual que si la entrada no
existiera. (Esto difiere de PostScript, donde null se comporta como cualquier otro
objeto como valor de una entrada de diccionario.) El número de entradas en un
diccionario estará sujeto a un límite de implementación; ver Anexo C. Un diccionario
puede tener cero entradas.
Las entradas en un diccionario representan una tabla asociativa y, como tal, no tienen
un orden, aunque se puede imponer un orden arbitrario sobre ellas cuando se escriben
en un archivo. Ese orden será ignorado.
No se deben tener entradas múltiples en el mismo diccionario con la misma clave.
Un diccionario deberá escribirse como una secuencia de pares clave-valor encerrados

entre doble signo de menor y mayor que (usando los signos MENOR QUE (3Ch) y
MAYOR QUE (3Eh)).
EJEMPLO:
<<tipo /Ejemplo
/Subtipo / Ejemplo Diccionario
/Vesion 0.01
/Completamente 12
/Elemento de cadena (una cadena)
/ Subdiccionario<</ lteml 0.4
/11tem2 verdadero
/Último articulo (¡no!)
/Ultimo articulo (OK)
NOTA: No confundir los corchetes angulares dobles con los corchetes angulares
simples (y) utilizando el SIGNO MERNOR QUE (3Ch) y el SIGNO MAYOR QUE
(3Eh) que delimitan una cadena hexadecimal, (ver 7.3.4.3. "Cadenas
Hexadecimales").
Los objetos diccionario son los bloques fundamentales para construir un documento
PDF. Se usan comúnmente para recopilar y vincular los atributos de un objeto
complejo, como una fuente o una página del documento, con cada entrada en el
diccionario especificando el nombre y valor de un atributo. Por convención, la entrada
Tipo de tal diccionario, si está presente, identifica el tipo de objeto que describe el
diccionario. En algunos casos, puede usarse una entrada Subtipos (a veces abreviada
como S) para identificar una subcategoría especializada del tipo general. El valor de
las entradas Tipo o Subtipo debe ser siempre un nombre. Por ejemplo, en un
diccionario de fuente, el valor de la entrada Tipo será siempre Fuente, mientras que el
de la entrada Subtipo puede ser Tipo1, Tipo verdadero, u otros valores.
7.3.8 Objetos de Flujo
7.3.8.1 Generalidades
Un objeto de flujo, como un objeto cadena, es una secuencia de bytes. Además, un

flujo puede tener una longitud ilimitada, mientras que una cadena estará sujeta a un
límite de implementación. Por esta razón, los objetos con datos potencialmente
grandes, como imágenes y descripciones de páginas, deberán representarse como
flujos.
NOTA 1: Esta subcláusula describe solo la sintaxis para escribir un flujo como una
secuencia de bytes. El contexto en el que se hace referencia a un flujo determina qué
representan los bytes de la secuencia.
Un flujo deberá consistir en un diccionario seguido de cero o más bytes, encerrados

entre las palabras clave stream (seguida de un salto de línea) y endstream.
EJEMPLO:
diccionario
stream
…(cero o más bytes)
endstream
Todas los streams serán objetos indirectos (ver 7.3.10. "Obetos indirectos ") y el
Diccionario de streams deberán ser un objeto directo. La palabra clave stream que
sigue al Diccionario de streams debe ser seguido por un marcador de extremo de línea
que consiste en un RETORNO DE CARRO y un SALTO DE LINEA o solo u
SALTO DE LINEA, y no por un RETORNO DE CARRO solo. La secuencia de bytes
que conforman un stream se encuentran entre el marcador de extremo de línea
después de la palabra clave stream y la palabra clave edstream; El Diccionario
stream especifica el número exacto de bytes. Debe haber un marcador de fin de línea
después de la data y antes de edstream; Este marcador no se incluirá en la longitud
del stream. No deberá haber ningún tipo de bytes adicionales, aparte de espacio en
blanco, entre endstream y endobj.
Alternativamente, comenzando con PDF 1.2, los bytes pueden estar contenidos en un
archivo externo, en cuyo caso, el diccionario de la transmisión especifica el archivo, y
cualquier bytes entre stream y edstream será ignorado por un lector conforme.
NOTA 2 Sin la restricción de seguir el stream de palabras claves con un solo

RETORNO DE CARRO solo, sería imposible para diferenciar un stream que utiliza
el RETORNO DE CARRO como marcador de fin de linea y tiene SALTO DE LINEA
como el primer byte de datos de uno que utiliza una secuencia de RETORNO DE
CARRO-SALTO DE LINEA para denotar la línea en la línea.
La Tabla 5 enumera las entradas comunes a todos los diccionarios de Stream; Ciertos
tipos de flujos pueden tener entradas de diccionarios adicionales, como se indica
dónde se describen esas corrientes. Las entradas opcionales con respecto a los filtros
para el flujo indican si y cómo elLos datos en la corriente se transformarán
(decodificados) antes de que se utilice. Los filtros se describen más en 7.4, "Filtros".
7.3.8.2 Extensión de la corriente
Cada Diccionario de stream tendrá una entrada de longitud que indique cuántos bytes
del archivo PDF se usan para los datos de flujo. (Si el stream tiene un filtro, la
longitud debe ser el número de bytes de datos codificados). Además, la mayoría de
los filtros se definen para que los datos sean autolimitados: es decir, usan un esquema
de codificación en el que se encuentran un marcado explícito de fin de datos (EOD).
Delimita la extensión de los datos. Por último. Los stream se utilizan para representar
muchos objetos de cuyos atributos se pueden inferir una longitud. Todas estas
restricciones serán consistentes.
Ejemplo Una imagen con 10 filas y 20 columnas, utilizando un solo color de compone
de color y 8 bits por componente, requiere exactamente 200 bytes de datos de imagen.
Si el stream usa un filtro, deberán haber suficientes bytes de datos codificados en el
archivo PDF para producir esos 200 bytes. Se produce un error si la longitud es
demasiado pequeña, si un marcador EOD explícito aparece demasiado pronto. o si los
datos decodificados no contienen 200 bytes.
También es un error si el stream contiene demasiados datos, con la excepción de que
puede haber un marcador de extremo de línea adicional en el archivo PDF antes de la
palabra clave endstream.
Tabla 5 - Entradas Comunes a todos los diccionarios de Stream

Llave Tipo Valor
Longitud número entero (Requerido) el número de bytes desde el principio de
la línea despues de la palabra clave stream al último byte justo antes de la palabra
clave endstream. (Puede haber un marcador de EOL adicional. Precediendo el
endstream. Eso no está incluido en el conteo y no es lógico.una parte de los datos de
stream). Vea 7.3.8.2. "Extensión de stream". para una mayor discusión.
Filtro Nombre o matriz (Opcional) El nombre de un filtro que se aplicará en el

procesamiento de los datos de la transmisión encontrados entre las palabras clave
stream y endstream. O una matriz de cero, uno o varios nombres. Se especificarán
múltiples filtros en el orden en que se deben aplicar..
Decodeparms Diccionario o matriz (Opcional) Un diccionario de parámetros

o una matriz de dichos diccionarios. utilizado por los filtros especificados por filtro.
Si solo hay un filtro y ese filtro tiene parámetros. Decodeparms se establecerá un
diccionario de parámetros de Filtros a menos que todos los parámetros del filtro
tengan sus valores predeterminados. En cuyo caso se puede omitir la entrada de
decodeparms. Si hay múltiples filtros y cualquiera de los filtros tiene parámetros
establecidos en valores distintos de los predeterminados. Decodeparms será una
matriz con una Entrada para cada filtro: el diccionario de parámetros para ese filtro, o
el objeto nulo si ese filtro no tiene parámetros (o si todos sus parámetros tienen sus
valores predeterminados). Si ninguno de los filtros tiene parámetros, o si todos sus
parámetros tienenValores de fallas, la entrada de Decodeparms se puede omitir.
F Especificación de archivo (Opcional: PDF 1.2) El archivo que contiene los datos
de stream. Si esta entrada está presente, se ignorarán los bytes entre stream y
endstream. Sin embargo. La entrada de longitud aún debe especificar el número de
esos bytes (generalmente, no hay bytes y la longitud es 0). Los filtros que se aplican a
los datos del archivo deben ser especificados por FFilter y los parámetros del filtro
deben ser especificados por FdeCodeparms.
FFi1ter Nombre o matriz (Opcional: PDF 1.2) El nombre de un filtro que se

aplicará en el procesamiento de los datos que se encuentran en el archivo externo de
stream, o una matriz de cero. uno o varios tales nombres. Las mismas reglas se aplican
en cuanto al filtro.
FDecodeparms Diccionario o matriz (Opcional: PDF 1.2) Un diccionario de
parámetros. o una matriz de dichos diccionarios. utilizado por los accesorios
especificados por FFilter. Las mismas reglas se aplican en cuanto a Decodeparms.
Tabla 5 - Entradas comunes a todos los diccionarios de Stream (continuación)
Llave Tipo Valor
DL entero (Opcional: PDF 1.5) Un entero no negativo que representa el número de

bytes en el stream decodificado (desfilada). Puede usarse para determinar, por
ejemplo, ya sea suficiente espacio en disco disponible para escribir un stream a un
archivo.
Este valor será considerado solo; Para algunos filtros de stream. Puede que no sea
posible determinar este valor precisamente.
7.3.9 Objeto nulo
El objeto nulo tiene un tipo y valor que son desiguales para los de cualquier otro
objeto. Sólo habrá un objeto de tipo nulo. denotado por la palabra clave nulo. Una
referencia indirecta de objetos (ver 7.3.10, "objetos indirectos") a un objeto inexistente
será tratado igual que un objeto nulo. Especificar el objeto nulo como el valor de una
entrada de diccionario (7.3.7, "Objetos de diccionario") será equivalente a omitir la
entrada por completo.
7.3.10 Objetos indirectos
Cualquier objeto en un archivo PDF puede ser etiquetado como un objeto indirecto.
Esto le da al objeto un identificador de objeto único por el cual otros objetos pueden
referirse a él (por ejemplo, como un elemento de una matriz o como el valor de una
entrada de diccionario). El identificador del objeto constará de dos partes:
 Un numero entero positivo de objeto. Los objetos indirectos pueden ser

numerados secuencialmente dentro de un archivo PDF, pero esto no se requiere;
Los números de objetos pueden asignarse en cualquier orden arbitraria.
 Un número de generación de enteros no negativos. En un archivo recién creado.
Todos los objetos indirectos deberán tener generado.Los números de iones de
los números de generación de 0. Se pueden introducir números de generación
distintos de cero cuando el archivo se actualiza posteriormente; Consulte las
subcláuses 7.5.4, "Tabla de referencia cruzada" y 7.5.6, "Actualizaciones
incrementales".
Juntos, la combinación de un número de objeto y un número de generación

identificaran de forma unica un objeto.
La definición de un objeto indirecto en un archivo PDF consistirá en su número de
objeto y número de generación (separado por el espacio en blanco). seguido del valor
del objeto entre las palabras clave obj y endobj.
Ejemplo 1 Definición de objeto indirecto

12 0 obj
(Brillig)
endobj
Define un objeto de cadena indirecta con un número de objeto de 12, un número de

generación de 0, y el valor Brillig.
El objeto puede ser referido de otra parte del archivo por una referencia indirecta.
TalLas referencias indirectas constarán del número de objeto. El número de
generación, y la palabra clave R (con espacio en blanco que separa cada parte):
12 0 R
Comenzando con PDF 1.5. Los objetos indirectos pueden residir en las transmisiones
de objetos (ver 7.5.7. "Streams de objetos"). Son referido de la misma manera; sin
embargo. Su definición no incluirá las palabras clave obj y endobj, y su número de
generación será cero.
Una referencia indirecta a un objeto no definido no se considerará un error por un

lector conforme, deberá bE tratado como una referencia al objeto nulo.
Ejemplo 2 Si un archivo contiene la referencia indirecta 17 0 R, pero no contiene la

definición correspondiente, se considera que la referencia indirecta se considera para
referirse al objeto NULL.
Excepto que se documentaron al contrario cualquier valor de objeto puede ser una
referencia directa o indirecta; La semántica es equivalente.
Ejemplo 3 A continuación, muestra el uso de un objeto indirecto para especificar la

longitud de un flujo. El valor de la longitud de la corriente.La entrada es un objeto
entero que sigue al flujo en el archivo. Esto permite que las aplicaciones generen PDF
en un solo paso para diferir la longitud de la secuencia hasta después de que se hayan
generado su contenido.
7 0 obj
Longitud 8 0 r % Una referencia indirectaa objeto 8 stream BT
F1 12 TF
72 712 td
(Un stream con una longitud indirecta) Tj ET
Endstream
Endonj final
8 0 obj
77 % La longitud del flujo anterior endObj
7.4 Filtros
7.4.1 General
Los filtros de stream se introducen en 7.38, "Objetos de la secuencia". Una opción al

leer los datos de la transmisión es decodificarlo utilizando un filtro para producir los
datos originales no codificados. Ya sea para hacerlo y qué filtro de decodificación o
filtros a usar se pueden especificar en el diccionario de stream.
EJEMPLO 1 Si un diccionario de stream especifica el uso de un filtro

ASCIIhexDecode, una aplicación que lee los datos en ese stream debe transformar los
datos codificados de ASCII hexadecimal en esa transmisión para obtener los datos
binarios originales.
Un escritor de nforming puede codificar los datos en un stream (por ejemplo, los datos
para las imágenes muestreadas) para comprimirla o convertirla a una representación
de ASCII portátil (o ambas). Un lector conforme se invocará el filtro de
decodificación correspondiente o los filtros para convertir el enFormación de nuevo a
su forma original.
El filtro o los filtros para una corriente se especificarán mediante la entrada del filtro
en el diccionario de stream (o la entrada de FFilter si la secuencia del stream es
externa). Los filtros pueden estar en cascada para formar una tubería que pasa la
transmisión. Dos transformaciones en bruto o más de decodificación en secuencia. Por
ejemplo, los datos codificados que se codifican utilizando la codificación LZW y
ASCII BASE-85 (en ese orden) se decodificarán utilizando la siguiente entrada en el
diccionario de stream:
Ejemplo 2 Filtro Vasc1185DECODE / LZWDECODEJ
Algunos los filtros pueden tomar parámetros para controlar cómo operan. Estos
parámetros opcionales deberán ser especificados por la entrada de Decodeparms en el
diccionario de Stream (o la entrada de FDecodeParms si el stream es externo).
PDF admite un conjunto estándar de filtros que caenen dos categorías principales:
 Los filtros ASCII permiten la decodificación de datos binarios arbitrarios que se
han codificado como texto ASCII (ver 7.2, "Convenios léxicos", para obtener
una explicación de por qué este tipo de codificación puede ser útil).
 Los filtros de descompresión habilitan la decodificaciónde datos que se han

comprimido. Los datos comprimidos deberán estar en formato binario, incluso
si los datos originales son el texto ASCII.
Nota 1
Los filtros ASCII no sirven un propósito útil en un archivo PDF que está encriptado;
Ver 7.6, "Cifrado".
Nota 2
La compresión es particularmente valiosa para imágenes muestreadas grandes, ya que
reduce los requisitos de almacenamiento y el tiempo de transmisión. Algunos tipos de
compresión son losos, lo que significa que algunos datos se pierden durante la
codificación, lo que resulta en una pérdida de calidad cuando alguna dato es
descomprimido. La compresión en la que ocurre ninguna pérdida de datos se llama
pérdida de pérdida. Aunque de alguna manera obvia podría valer la pena señalar que
la compresión con pérdida solo se puede aplicar a los datos de la imagen de
muestreados (y solo ciertos tipos de compresión con pérdida para ciertos de
imágenes). La compresión sin pérdidas, por otro lado, se puede usar para cualquier
tipo de flujo.
Los filtros estándar se resumen en la Tabla 6, que también indican si aceptan cualquier
parámetro opcional. Las siguientes subcláuses describen estos filtrados.ers y sus
parámetros (si los hay) con mayor detalle, incluidas las especificaciones de los
algoritmos de codificación para algunos filtros.
Tabla 6 - Filtros estándar
Nombre del filtro Parámetros Descripción
Asciihexdecode no Decóques datos codificados en una representación

hexadecimal ASCII, reproduciendo los datos binarios originales.
Asc1185decode Decodifica los datos codificados en una representación

ASCII BASE-85. Reproducción de los datos binarios originales.
Lzwdecode Descomprime los datos codificados utilizando el método de

compresión adaptable I-ZW (Lempel-Zivwelch). Reproducción del texto original o
datos binarios.
Flatedecode (PDF 1.2) descomprime los datos codificados con el método de
compresión ZLIB / Deflate, lo que reproduce el texto original o los datos binarios.
Runlengthdecode no Descomprime los datos codificados utilizando un algoritmo

de codificación de longitud de ejecución orientada a bytes, reproduciendo el texto
original oDatos binarios (datos de imagen típicamente monocromáticos, o cualquier
dato que contenga carreras largas frecuentes de un solo valor de bytes).
Ccittfaxdecode sí Descomprime los datos codificados utilizando el estándar de

FAXIMILE CCITT, lo que reproduce los datos originales (generalmente los datos de
la imagen monocromáticos en 1 bit por píxel).
Jblg2decode (PDF 1.4) descomprime los datos codificados con el estándar

JBLG2, lo que reproduce los datos de imagen original monocromo (1 bit por píxel) (o
una aproximación de esos datos).
Dctdecode
Descomprime los datos codificados utilizando una técnica de DCT (Transformación
de coseno discreto) basada en el estándar JPEG. Reproducción de imágenes de
muestra de imagen que se aproximan a los datos originales.
Jpxdecode
(PDF 1.5) descomprime los datos codificados utilizando el soporte de JPEG2000
basado en WavelETARD, reproduciendo los datos de la imagen originales.
Cripta
(PDF 1.5) descifra los datos cifrados por un controlador de seguridad. Reproducción
de los datos tal como fue antes del cifrado.
Ejemplo 3 El siguiente ejemplo muestra un flujo. que contiene las instrucciones de

marcado para una página, que se comprimió utilizando el método de compresión LZW
y luego se codificó en la Representación ASCII BASE-85.
1 0 obj
Longitud 534
'Filtro (ASC1185DECODO ILZWDECODOTE)
Stream
Endobj
final
Ejemplo 4 A continuación se muestran stream sin filtros aplicados a ella. (Los
contenidos de stream se explican en 7.82 "contenidos de stream", y los operadores
utilizados se describen en la cláusula 9, "Texto").
1 0 obj
Longitud 568 stream
2J
BT
FI 12 TF
0 Tc
0 Tw
72.5 712 td
[(Las secuencias de stream se pueden leer fácilmente) 65 (, TJ
0 -14 TD
(b) 20 (ut generalmente TAK) 10 (e más espacio que Tj
T* (Streams comprimidos.) TJ
0 -28 TD [(Se) 25 (V) 15 (Área de Métodos de codificación de ERA) 20 (V) 25
(disponible en PDF) 80 (.) TJ 0 -14 TD
(Algunos se utilizan para la compresión y otros simplemente) TJ
T* [(para representar datos binarios en A) 55 (formato ASCII)] TJ
T*(Algunos de los filtros de compresión son sutitable) tj
T *(para datos e imágenes, mientras que otros son solamente adecuado) tj
(Para imágenes de tono continuo.) TJ
ET
endstream
Endobj final
7.4.2 Filtro ASCIIHexDecode
El filtro ASCIIHexDecode Decodifica los datos que se han codificados en format

hexadecimal ASCII. La codificación hexadecimal y la codificacion ASCII base-85
(7.4.3, Filtro ASC1185Decode) Convierta datos binarios, como datos de imagen o
datos previamente comprimidos, a caracteres ASCII de 7 bits.
Nota: se prefiere la codificación ASCII base-85 a la codificación ASCII hexadecimal.

Se prefiere la codificación BASE-85 porque es más compacta: expande los datos por
un factor de 4: 5, en comparación con 1: 2 para la codificación hexadecimal ASCII
hexadecimal.
El filtro ASCIIHexDecode debe producir un byte de datos binarios para cada par de
digitos ASCII hexadecimal (0-9 y o A-F O a-f). Todos los caracteres del espacio en
blanco (ver 7.2, "Convenciones léxicas") serán ignoradas. Un SIGNO MAYOR QUE
(3eh) indica EOD. Cualquier otro carácter debe causar un error. Si el filtro encuentra
el marcador EOD después de leer un número impar de dígitos hexadecimales, se
comportará como si una 0 (cero) siguiera al último dígito.

traduccion

Cargado por

Copyright:

Formatos disponibles

traduccion

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

traduccion

Cargado por

Copyright:

Formatos disponibles

Contenidos Página

Resumen del operador 643

Operadores en funciones tipo 4 647

Límites de implementación. 649

Conjuntos de personajes y codificaciones 651

Registro de nombre PDF 673

PDF linealizado 675

Ejemplo de archivos PDF 699

Versiones PDF y Compatibilidad 727

PDF Ejemplo de Implementación de Cambio de Nombre de Bandera 729

Compatibilidad PostScript - Modelo de imágenes transparente 731

Placas de color 733

El 29 de enero de 2007, Adobe Systems Incorporated anunció la intención de lanzar el

PDF se ha convertido en una norma global de facto para un intercambio de

Nota técnica #5116. Compatibilidad con filtros DCT en PostScript Nivel 2,

Nota técnica #5177. El formato de cadenas de caracteres tipo 2 (Type 2 Charstring

NOTA 5: Los siguientes documentos están disponibles como publicaciones de

 FIPS PUB 186-2, Digital Signature Standard (Estándar de firma digital),

RFC 1738, Localizadores uniformes de recursos (URLs), (diciembre de 1994),

RFC 1808, Localizadores uniformes de recursos relativos (Relative URLs), (junio

RFC 1951, Especificación del formato de datos comprimidos DEFLATE, versión

RFC 2045 y 2046, Extensiones multipropósito de correo de Internet (MIME),

RFC 2396, Identificadores uniformes de recursos (URI): Sintaxis genérica, (agosto

RFC 2616, Protocolo de transferencia de hipertexto—HTTP/1.1, (junio de 1999),

RFC 2898, PKCS #5: Especificación de criptografía basada en contraseñas,

RFC 3066, Etiquetas para la identificación de idiomas, (enero de 2001), Grupo de

RFC 3161, Protocolo de marcas de tiempo para infraestructura de clave pública

RFC 3174, Algoritmo de resumen seguro de EE. UU. 1 (SHA-1), (septiembre de

RFC 3280, Infraestructura de clave pública X.509 en Internet: Perfil de

NOTA 7: Los siguientes documentos están disponibles de otras fuentes:

Formato de fuente Adobe Type 1, Versión 1.1, (Febrero de 1993), Addison-Wesley,

Especificación de fuente Tipo abierto 1.4, (Diciembre de 2004), Microsoft.

Manual de referencia Tipo verdadero, (Diciembre de 2002), Apple Computer, Inc.

Estándar ECMA-363, Formato de archivo 3D universal, 1ª Edición (U3D),

Guía de métricas de clasificación PANOSE, (Febrero de 1997), Hewlett-Packard

El estándar Unicode, Versión 4.0, Addison-Wesley, Boston, MA, 2003, Consorcio

Anexos del estándar Unicode: #9 (Algoritmo bidireccional), #14 (Propiedades de

4.2 Valor de 8 bits (ver byte)

4.3 Objeto array: una colección unidimensional de objetos dispuestos

4.4 ASCII: el Código Estándar Americano para el Intercambio de Información, una

4.5 Datos binarios: una secuencia ordenada de bytes.

NOTA 1 Hay tres manifestaciones de caracteres en PDF, dependiendo del contexto:

 Un archivo PDF se representa como una secuencia de bytes de 8 bits, algunos

4.10 Conjunto de caracteres: un conjunto definido de símbolos, cada uno asignado a

4.11 Lector conforme: aplicación de software que es capaz de leer y procesar

4.12 Producto conforme: aplicación de software que es tanto un lector conforme

4.15 Tabla de referencias cruzadas: estructura de datos que contiene el

4.18 Objeto directo: cualquier objeto que no ha sido convertido en un objeto

4.19 Documento electrónico: representación electrónica de una agregación orientada

4.22 Filtro: una parte opcional de la especificación de un objeto de flujo, indicando

4.24 Función: un tipo especial de objeto que representa clases parametrizadas,

4.25 Glifo: símbolo gráfico abstracto reconocible que es independiente de cualquier

4.34 Objeto numérico: ya sea un objeto entero o un objeto real.

4.41 Diccionario de recursos: asocia nombres de recursos, utilizados en flujos de

4.42 Carácter de espacio: carácter de cadena de texto utilizado para representar

NOTA 2 Los caracteres de espacio incluyen TABULACIÓN HORIZONTAL

4.45 Captura de web: se refiere al proceso de crear contenido PDF mediante la

4.46 Carácter de espacio en blanco: caracteres que separan construcciones

Los caracteres de token utilizados para delimitar objetos y describir la estructura de

EJEMPLO 1: Espacio (U+2002).