Antecedentes III: Gestión de fuentes PDF

Capítulo 5
Antecedentes III: Gestión de
fuentes PDF
5.1.
Introducción
En este capítulo vamos a introducir las capacidades básicas existentes en PDF para el
tratamiento de textos, y más en concreto, para la representación de caracteres, partiendo de
los glifos o formas gráficas que proporciona una fuente. Es un capítulo de especial relevancia
en este proyecto y por este motivo se le dedica una mayor atención. En él se presenta una
visión general de las estructuras y entidades empleadas para la reproducción de textos1 ,
siguiendo una organización que parte de los conceptos de más bajo nivel para avanzar hacia
los de más alto nivel, es decir, desde el concepto de los propios glifos hasta el análisis de los
text objects and operators (los objetos y operadores de texto), text state (el estado del texto)
y font data structures (las estructuras de datos de fuente).
5.2.
Organización y uso de fuentes
En esta primera sección se describen los conceptos fundamentales de la organización y uso
de las fuentes en PDF.
Es importante realizar una distinción inicial de dos conceptos que suelen confundirse de
forma general en estudios tipográficos en computadores, el carácter y el glifo. Un carácter se
define como un símbolo abstracto, mientras que un glifo es una representación gráfica de un
carácter. Consideremos un ejemplo sencillo; los glifos A, A y A son representaciones gráficas
de un mismo carácter, el carácter "A". Sin embargo, la historia demuestra que esta distinción
entre caracteres y glifos, no siempre se ha tenido en cuenta en las disciplinas tipográficas en
el mundo de la computación y se han empleado de forma indistinta, de ahí que en muchas
1 Según
se determina en las especificaciones de PDF 1.7.
45
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
46
ocasiones encontremos que los nombres de estructuras y términos de PDF no se ajustan
a lo que realmente representan y que constituyen un vocabulario residual resultado de la
herencia del pasado. No obstante, es esencial tener presente la diferencia para que no surjan
dificultades en la comprensión de este capítulo.
El siguiente concepto que debe considerarse es el de fuente. Los glifos se organizan en fuentes,
es decir, una fuente define los glifos a emplear para un conjunto determinado de caracteres.
Fuentes como Arial o Times New Roman definen los glifos (estructuras gráficas) para representar un conjunto estándar de caracteres latinos. Para que una aplicación de gestión de
PDF pueda emplear una fuente, ésta debe de encontrarse en forma de programa y de ahí que
surja un nuevo concepto, los programas de fuentes o font programs. Los font programs están
escritos en un lenguaje de propósito específico, como son los formatos de fuente Type 1 o
True Type, que son traducidos por intérpretes de fuentes especializados y que se explicarán
más adelante. Los font programs contienen entonces, definiciones de glifos que pueden ser
traducidos para generar glifos.
Con estos conceptos generales de tipografía podemos adentrarnos ya en el formato PDF
en concreto. En PDF, un objeto fuente o diccionario de fuente se encarga de identificar el
programa fuente e información adicional a éste. A este objeto es lo que se llama fuente, que
como vemos no se corresponde en sentido estricto con la definición de fuente dada arriba.
Los objetos fuente o fuente simplemente en PDF, no se traducen en programas sino que son
estructuras que identifican o señalan a un programa fuente y que además, especifican otros
parámetros de interés para la correcta definición de la fuente a emplear. Por otro lado, los
objetos fuente discriminan entre distintos tipos de fuentes que se identifican mediante una
entrada en su diccionario llamada Subtype.
Una cuestión esencial para este proyecto es la localización de los programas fuente o font
programs. En la mayoría de los tipos de fuentes en PDF, estos programas se encuentran
en un fichero (font file) fuera de la propia definición del objeto fuente. Este font file puede
hallarse tanto incrustado dentro del propio fichero PDF en forma de objeto de flujo de datos
(PDF stream object) como obtenerse de un fichero externo. Como ya se ha planteado en los
objetivos de este proyecto, sería deseable que estos programas fuente se encontraran siempre
embebidos dentro del propio fichero PDF, de forma que se alcance la máxima autonomía
posible respecto del sistema en que se visualice o manipule el fichero. No es eficiente que la
representación de un PDF dependa de que en nuestro dispositivo se encuentren presentes los
ficheros fuente que se necesitan para la correcta visualización, como además, no es admisible
en términos de fidelidad a la realidad, que dejemos al visualizador o programa PDF que
realice una representación aproximada mediante fuentes adaptables, de la tipografía de la
fuente de que no se dispone, atendiendo a las métricas que se conocen de la original.
Para el proceso de visualización de un determinado texto o Showing Text, son necesarios tres
elementos que ya han sido definidos en el capítulo anterior; content stream, string object y
font dictionary. El content stream se encarga de la representación de los glifos en la página,
previa especificación de un font object y un string object. Se trata por tanto, de un proceso en
el que la secuencia de códigos de caracteres de un string object es interpretada por el content
stream, para seguidamente realizar la asociación de los caracteres con los correspondientes
glifos que se especifican el font object. Sin embargo, este proceso sólo muestra un comportamiento abstracto de la implementación real, dado que por ejemplo, en muchas ocasiones
se consiguen implementaciones más efectivas mediante el almacenamiento en caché de los
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
47
glifos que se van empleando, acelerando el proceso de conversión mediante la reutilización.
En la siguiente sección vamos a estudiar más en profundidad este proceso.
5.2.1.
Introducción al proceso básico de visualización de texto o
Showing Text
Se presenta a continuación un ejemplo básico de la utilización directa de una fuente en PDF.
En el ejemplo 5.1 se muestra un objeto de texto o text object.
Ejemplo 5.1
BT
/F13 12 Tf
288 720 Td
( texto-de-muestra ) Tj
ET
Se pueden distinguir las siguientes partes. Las primera y última línea se corresponden con
la inicialización y finalización del objeto de texto. En la segunda se especifica el nombre y
el tamaño de la fuente a emplear y se almacenan como parámetros en el estado del texto o
text state. Para especificar el nombre de la fuente a emplear se hace uso de su identificador
de font resources. En este caso, F13 hace referencia a la fuente que externamente se conoce
como Helvética y se le asigna un tamaño de fuente de 12 puntos. A continuación, en la
siguiente línea, se establece la localización del punto inicial donde ha de comenzar el texto,
pasando también a formar parte de los parámetros del estado del texto. En este ejemplo,
la cadena comienza a 10 pulgadas desde el fondo de la página y a 4 pulgadas del extremo
izquierdo. La cadena de caracteres a mostrar, "texto-de-muestra", se encuentra en la cuarta
línea, entre paréntesis, al tratarse de una cadena literal.
Una vez definidas las distintas secciones de un objeto de texto básico, se analizan las operaciones que se llevan a cabo para realizar el Showing Text.
Identificación de la fuente
En primer lugar, el content stream identifica la fuente que se necesita. El operador Tf
indica el nombre del recurso de fuente a emplear, el cual no es más que una entrada
en el diccionario de recursos de fuentes que a su vez, es una entrada en el diccionario
de recursos de la página actual. Esta entrada, con el nombre en este ejemplo de F13,
en el subdiccionario de recursos de fuentes se corresponde con una referencia a un
objeto fuente o diccionario fuente que ya hemos introducido en este capítulo. De esta
manera, el content stream dispone de toda la información relativa a la fuente que
requiere, teniendo en cuenta que el font object proporciona el nombre externo de la
fuente, información complementaria y, de forma opcional, la definición misma del font
program. Por otra parte, es importante señalar que una fuente define glifos de un
tamaño estándar y que se debe establecer un factor de escala que se ajuste a los
requisitos. En este caso el factor de escala se especifica como segundo argumento del
operador Tf y es 12.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
48
En el ejemplo 5.2 se muestra un fragmento de un diccionario de recursos de una determinada página. Se puede a su vez distinguir el subdiccionario de recursos de fuente, donde
se especifican las fuentes que se emplean en dicha página y entre las que se encuentra la
empleada en el ejemplo 5.1 (Helvética en este caso) a través de la entrada F13. Esta entrada
no es más que una referencia a un objeto fuente (con número de referencia 23 0), el cual se
muestra también en este ejemplo tras el extracto del diccionario de recursos de página que
acabamos de comentar.
Ejemplo 5.2
/Resources Extracto de diccionario de recursos
< </Font
< </F13 23 0 R > > % Subdiccionario de recursos fuente
>>
23 0 obj % Objeto o diccionario fuente
<<
/Type /Font
/Subtype /Type1
/BaseFont /Helvetica
>>
endobj
Generación de los glifos
Una vez que se ha determinado la fuente y el valor de escala a emplear, se procede
a la generación de los glifos. En primer lugar, el operador Td fija la posición del
texto en la página, partiendo del sistema actual de coordenadas del usuario, para que
seguidamente, el operador Tj comience a dibujar los glifos. Para esto, Tj se basa en
la información que ya conoce de la fuente. En caso de fuentes sencillas como las fuente
latinas ordinarias, toma la cadena de texto que se le da como parámetro, que en el
ejemplo es "texto-de-muestra", y trata a cada uno de sus elementos como un código de
carácter (un entero entre 0 y 255). El código de un carácter selecciona una descripción
de glifo de la fuente y dicha descripción se ejecuta para para dibujar el glifo en la
página. Esta interpretación de la cadena de texto como una secuencia de códigos de
carácter en el caso de las fuentes compuestas, es una operación más compleja y se
explicará en la sección dedicada a dichas fuentes.
5.2.2.
Desplazamiento y otras métricas de glifos
En las especificaciones de PDF [7], se define la anchura (width) de un glifo como el desplazamiento horizontal o espacio de translación del texto, es decir, la distancia que un glifo
ocupa a largo de la coordenada horizontal o la cantidad de espacio en que se desplaza la
posición inicial, en dicha dirección, del siguiente glifo a dibujar. Es importante remarcar que
este término nada tiene que ver con la anchura del glifo en cuanto a las dimensiones de su
contorno. En las fuentes de tipo fixed-pitch la anchura es un parámetro constante que no
varía de un glifo a otro. Sin embargo, en las fuentes que se emplean para tipografía de alta
calidad, se asocia a cada glifo una anchura distinta y se les denomina fuentes proporcionales
o variable-pitch fonts.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
49
Figura 5.1: Desplazamiento de glifo
El encargado de posicionar los glifos consecutivos de una cadena de acuerdo con sus anchuras, es el operador Tj, que rescatará esta información del diccionario de fuente y/o del
programa fuente mismo que ha indicado Tf. La razón por la que se puede encontrar la
misma información sobre las anchuras en dos lugares a la vez de forma redundante, es para
permitir que una aplicación pueda ser capaz de ahorrarse el acceso a dicha información en
el interior del programa fuente, acelerando el proceso al tomar esta información del diccionario de fuente directamente. En cualquier caso, las anchuras de ambos elementos deben
ser coherentes entre si. Además, éstas son susceptibles a modificaciones respecto a su tamaño
estándar mediante el operador Tj y otros métodos que permiten un ajuste de los caracteres
y espaciamiento entre palabras de forma sistemática.
A parte de la anchura, un glifo dispone de otras muchas métricas que influyen en su posicionamiento y representación. Salvo para el caso de las fuentes Type 3, que estudiaremos en
la sección dedicada a fuentes simples, estas métricas adicionales se encuentran englobadas
dentro del programa fuente y no se especifican de forma explícita en el objeto fuente como
puede ocurrir en el caso de las anchuras, tal y como se ha explicado arriba.
Por otro lado, es cierto que en la mayoría de los sistemas de escritura occidentales, el desplazamiento de un glifo a otro contiene sólo una componente horizontal. Sin embargo, en
muchos de los sistemas de escritura asiáticos como el japonés o el chino, se tiene presente
un desplazamiento o bien sólo vertical o una composición en ambas direcciones, de forma
que se habla de vector de desplazamiento de glifo, que contendrá información más amplia
que la simple anchura. Para poder elegir entre los distintos tipos de opciones en la dirección
de escritura en estos sistemas, surge un nuevo parámetro llamado el writing mode (modo de
escritura). Cuando éste toma el valor 0, se especifica una dirección horizontal, mientras que
si su valor es de 1, se especifica una desplazamiento vertical. En la sección dedicada a las
fuentes compuestas estudiaremos más en profundidad esta métrica.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
50
En la figura 5.2 se muestra un glifo del lenguaje chino junto con distintos vectores de desplazamiento posibles que generan los distintos modos de escritura.
Figura 5.2: Modos de escritura
La información relativa a las métricas de los glifos se puede encontrar además, de forma
separada en forma de archivos AFM (Adobe Font Metrics) y ACFM (Adobe Composite Font
Metrics)[3]. Estos archivos suelen ser empleados por aplicaciones generadoras de descripciones de páginas de PDF que realizan ajustes del formato original, basándose en las anchuras y otras métricas de los glifos. Este tipo de archivos será fundamental en este proyecto
para la incrustación de fuentes Type 1 y de fuentes basadas en Type 1 como son las fuentes
MMType1 que se analizarán más adelante.
Otros tipos de métricas de glifo como son glyph bounding box, glyph coordinate system o
glyph origin no se detallan, dado que se escapan a nuestro objetivo y no tienen implicación
directa en el desarrollo de este proyecto. Sin embargo, es necesario comentar su existencia
como introducción a la descripción gráfica de los glifos de forma individualizada.
5.3.
El estado del texto: parámetros y operadores
El estado del texto comprende todos los parámetros gráficos que sólo tienen relación con
texto, desde el espaciado entre caracteres hasta el tamaño de la fuente. Gestiona pues nueve
parámetros (text state parameters) que se mantienen a un valor por defecto en cada página
(como todos los parámetros gráficos) hasta que son alterados por los text state operators
y que se consultan cada vez que se debe mostrar texto. Los text state operators no tienen
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
51
necesariamente que aparecer dentro de un objeto de texto y sin embargo, los valores que
asignan a cada parámetro son aplicables a todos los objetos de texto dentro de un mismo
content stream. Los parámetros del estado del texto son los que se muestran en el cuadro
5.1.
Parámetro
Tc
Tw
Th
Tl
Tf
Tfs
Tmode
Trise
Tk
Descripción
Espaciado entre caracteres
Espaciado entre palabras
Escalado horizontal
Entrelineado
Fuente
Tamaño de fuente
Relleno de contorno de glifo
Nivel de baseline
Bandera de independencia entre glifos
Cuadro 5.1: Parámetros del estado del texto
En el cuadro 5.2 se muestran los distintos operadores del estado del texto de forma compacta
y sus parámetros asociados.
Operador
Nombre
Descripción
charSpace
Tc
Espaciado entre caracteres,Tc.
wordSpace
Tw
Espaciado entre palabras, Tw.
scale
Tz
Escalado horizontal, Th.
leading
TL
Espaciado entre líneas, Tl.
font size
Tf
Fuente y tamaño de fuente, Tf y Tfs.
render
Tr
Relleno de contorno de glifo, Tmode.
rise
Ts
Nivel del baseline, Trise.
Cuadro 5.2: Operadores del estado de texto
Ejemplo
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
52
A continuación en el ejemplo 5.3, se presenta una instancia de content stream como ejemplo
de aplicación de los operadores listados arriba, es decir, para la alteración del estado del
texto.
Ejemplo 5.3
1 0 obj
< </Length 568 > >
% Inicio del stream
stream
2J
% Inicio objeto de texto
BT
/F1 12 Tf % Establecimiento del fondo: fuente y tamaño. La forma de indicación de fuente
mediante una entrada en el diccionario de recursos de fuentes resulta relevante en el desarrollo de
este proyecto.
0 Tc
% Especificación del espacio entre caracteres
0 Tw
% Asignación del espacio entre palabras
ET
endstream
endobj
5.4.
Los objetos de texto
Los objetos de texto se definen como una secuencia de operadores que permiten mostrar
cadenas de texto, cambiar la posición de éstas y asignar valores a los parámetros del estado
del texto. La estructura de un objeto de texto comienza con el operador BT, finaliza con el
ET y admite en su interior tres tipos de operadores distintos relacionados con textos: Text
state operators, Text-positioning operators y Text-showing operators. Dado que los primeros
ya han sido estudiados en la sección precedente, se pasa a analizar los otros dos tipos de
operadores.
Operadores de posicionamiento de texto
El espacio de texto o sistema coordenado donde se muestra texto, se especifica mediante la matriz de texto, Tm, junto con los parámetros del estado del texto Tfs, Th
y Trise, que deciden el espacio de usuario. Inicialmente, al comienzo de un objeto de
texto, la matriz Tm se corresponde con la matriz identidad, siendo entonces el origen
del espacio de texto igual al espacio de usuario. A medida que se van aplicando a dicha
matriz los operadores, tanto de posicionamiento de texto como de mostrado de texto,
se va actualizando su valor hasta conseguir el resultado final deseado tal y como se
explicará un poco más adelante en esta sección. Además, los objetos de texto deben
capturar el valor de Tm al comienzo de cada línea de texto y almacenarla en la matriz
de línea de texto Tlm, puesto que será un factor importante para conseguir el alineado
regular de las líneas de texto.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
53
Los operadores de posicionamiento junto con una breve descripción se muestran a en la
Tabla 5.3.
Operadores
Td
TD
Tm
T*
Descripción
Colocación al comienzo de la siguiente línea
Invoca Td y establece parámetro leading del estado del texto
Actualización de la matriz Tm
Mismo efecto que la invocación de consecutiva Tl y Td
Cuadro 5.3: Operadores de posicionamiento
Operadores de muestra de texto
Los operadores de muestra de texto o text-showing operators son los responsables de la
interpretación y aplicación de los parámetros del estado de texto a las cadenas que se
desean representar. Con la mayoría de fuentes, las cadenas de texto son interpretadas
como una secuencia de bytes y cada byte se trata como un código que identifica a un
glifo en concreto. Para identificar el glifo, se hace confrontar el código obtenido en el
paso anterior, con la codificación de la fuente. En el caso de las fuentes compuestas, la
identificación de los caracteres se realizará agrupando varias secuencias de bytes y una
vez extraídos éstos, se realizará el mapeado con sus correspondientes glifos atendiendo
a una estructura de datos llamada Cmap que se tratará en más profundidad en la
sección de fuentes compuestas.
El tamaño de las cadenas de texto no está sujeto a limitaciones y éstas pueden colocarse
en la página en cualquier orden, dado que la agrupación de glifos en cadenas no tiene
ninguna implicación en el modo en que se representan, aunque en caso de opciones
de búsqueda o extracción de textos, resulta significativamente más eficaz la formación
de cadenas de texto lo más largas posibles y organizadas en su orden natural. Por
otro lado, las cadenas deben ajustarse a la sintaxis de los objetos cadena y como
tales, deben, si se encuentran englobadas entre paréntesis y los valores de algunos de
sus caracteres coinciden con los valores de caracteres de ASCII paréntesis izquierdo,
paréntesis derecho o barra invertida, encontrarse precedidos de barra invertida. En la
Tabla 5.4 se resumen los operadores de muestra de texto.
Operadores
Tj
’
”
TJ
Descripción
Muestra la cadena de texto
Equivalente a invocación consecutiva de T* y Tj
Equivalente a invocación consecutiva de Tw, Tc y ’
Muestra de una o varias cadenas de texto consecutivamente
Cuadro 5.4: Operadores de muestra de texto
Después de que un glifo se haya dibujado, la matriz de texto se actualiza conforme a la
anchura de cada glifo y a todos aquellos parámetros de espaciamiento que deban aplicarse
como son Tc o Tfs.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
5.5.
54
Las estructuras de datos de fuente
Una vez que se ha comprendido el proceso de showing-text de forma general, es necesario
centrar la atención en un aspecto fundamental en su operación y que constituye el objeto
último de este proyecto, la gestión de fuentes dentro de la estructura de PDF. En esta sección
vamos a estudiar en profundidad la organización de las fuentes en PDF, su estructura interna
y la integración entre los distintos tipos de entidades de fuente. Resulta de gran relevancia
para la comprensión del desarrollo del proyecto, por lo que se dedica un especial detenimiento
y extensión.
Las estructuras de datos de fuente en PDF pueden resumirse en tres elementos fundamentales: los objetos fuente (font objects), los descriptores de fuente (font descriptors) y los
programas fuente (font programs). Los objetos fuente no son más que objetos diccionario,
que contienen información relativa al nombre externo o PostSript de la fuente, codificación
que se emplea, subtipo de fuente y otras informaciones relacionadas con métricas o referencias a descriptores de fuentes, que son objetos que especifican métricas y otros atributos
de una fuente, considerándola como un todo y no como un conjunto de glifos individuales.
Además, los descriptores de fuente son los objetos que se emplean para gestionar programas
fuente dentro de un fichero PDF, es decir, serán los estos descriptores los que nos permitan
incrustar programas fuente en el interior de un fichero.
En PDF se distinguen varios tipos de fuentes que se especifican mediante la entrada Subtype en el diccionario u objeto fuente. Estos tipos se pueden englobar dentro de dos grandes
grupos, las fuentes compuestas y las fuentes simples. Las fuentes compuestas están formadas
únicamente por las fuentes Type 0 o fuentes de tipo cero, que a su vez soportan dos objetos
relacionados con fuentes llamados CIDFonts y CMaps que sólo tienen sentido si son combinadas en una fuente Type0. Estos CIDFonts objects jugaran también un papel fundamental
para permitir la incrustación de fuentes compuestas y se estudiarán más detalladamente. En
la Tabla 5.5 se presentan las distintas opciones, su valor de subtipo dentro del diccionario
fuente y una breve descripción.
Tipo
Type0
Type1
Type3
True Type
Valor subtipo
CIDFontType0
CIDFontType2
Type1
MMType1
Type3
TrueType
Descripción
Fuente compuesta basada en la tecnología Type1
Fuente compuesta basada en la tecnología True Type
Fuente basada en la tecnología Type1
Extensión Type1: Multiple Master Font. Varias fuentes en una sola
Fuente basada en la descripción de glifos mediante PDF streams
Fuente basada en el formato de fuente True Type
Cuadro 5.5: Tipos de objetos fuente en PDF
Salvo en el caso de las fuentes Type3 que no necesitan del acceso a un programa fuente, dado
que se constituyen como autocontenidas, todas los font objects necesitan de un programa
fuente, ya se encuentre éste incrustado dentro del propio fichero PDF o fuera, en el sistema
actual. En cualquiera de los casos, incrustado o no incrustado en el PDF, el programa fuente
siempre se considera como un fichero aparte y al contrario que en el lenguaje PostScript,
sus contenidos son traducidos por un intérprete especializado cuando es necesario y nunca
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
55
se materializan como objetos PDF en formas similares a diccionarios fuente. Por otro lado,
la mayoría de los programas fuente siguen especificaciones externas como el Adobe Type1
Font Format [1] para el caso de las fuentes Type1, a las que más adelante se les dedicará
una mayor atención.
Los programas fuente pueden encontrarse como se ha señalado arriba, tanto dentro de un
fichero PDF como en el exterior o sistema actual y es aquí donde surge el problema. El
empleo de una fuente que no se encuentra incrustada, está sujeto a que su programa fuente
se encuentre disponible en el equipo donde se gestiona el PDF. Sin duda, esto constituye
una falta importante si se desea conseguir una trasmisión de documentos fiable, donde lo
que se tiene en el sistema originario sea igual a lo que se recibe en el sistema final sin tener que modificar nuestros dispositivos instalando nuevas fuentes según el fichero PDF que
recibamos, lo que sin duda puede ser una operación tediosa para usuarios no experimentados
en dichos temas y sobretodo costosa e innecesaria, dado que se debe generar un gasto en una
fuente que quizás nunca más tengamos que emplear. Además, las referencias a programas
fuente externos en PDF no tienen en cuenta todas las posibles particularidades del equipo
donde nos encontramos, como el nombrado de fuente o selección de glifos, que son dependientes de cada implementación en particular y que pueden variar entre distintos sistemas
operativos, lo que proporciona también un inconveniente para optar por el uso de fuentes
no incrustadas.
5.6.
Las fuentes simples
Las fuentes simples se engloban dentro de las estructuras de fuente en PDF y se caracterizan
por tres propiedades fundamentales.
1. Codificación
La interpretación de los códigos de caracteres a glifos de una determinada cadena
(dentro de un objeto de texto) en el proceso de Showing Text, se realiza byte a byte, lo
que da lugar a un conjunto de 256 posibilidades distintas. La correspondencia códigoglifo depende fuertemente del programa fuente asociado y de la codificación que se
indica en el font object, dado que cada programa fuente dispone de una codificación
interna que puede ser alterada mediante procedimientos que se explicarán en la sección
de codificación de fuentes.
2. Modos de escritura
En la Sección 5.2.2, "Desplazamiento y otras métricas de glifos" se analizaron los distintos modos de escritura en PDF, horizontal, vertical y mixto. En el caso de las fuentes
simples sólo es posible el modo de escritura horizontal o modo 0 de forma que si la
fuente a emplear exige el uso de otro modo es necesario acudir a las fuentes compuestas.
3. Descriptor de fuentes o font descriptor
Salvo casos excepcionales, todas las fuentes simples requieren de un diccionario auxiliar que contenga las anchuras y otras métricas de la fuente a emplear, esto es el font
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
56
descriptor que ya se ha introducido brevemente. A su vez, este diccionario puede hacer
uso de un font file stream que contenga el programa fuente correspondiente. En este
caso la fuente se encuentra incrustada.
Se pasa a continuación a analizar cada uno de los subtipos de fuentes que se introdujeron
en la sección 5.5.
5.6.1.
Las fuentes Type 1
Los programas fuente Type 1 [1] no son más que una variante de los programas PostScript
que describen glifos para una representación de alta calidad (incluso para pequeños tamaños
y bajas resoluciones) y pueden emplear una codificación compacta o Compact Font Format
[2]. Sin embargo, a pesar de emplear una sintaxis PostScript, las fuentes Type 1 no requieren
de intérpretes PostScript completos, sino de intérpretes de programas fuente Type 1 especializados. La descripción de las especificaciones que sigue este formato, Adobe Type1 Font
Format, se sale de los objetivos de este proyecto, aunque si se analizarán las propiedades de
las fuentes Type 1 más adelante, al igual que con el resto de tipos de fuentes que se emplean
en PDF.
Para poder comprender la sección de desarrollo de este proyecto, es necesario conocer en
profundidad la composición de los diccionarios fuente. Para las Type 1 se analizan a continuación cada una de las entradas y se señalará brevemente, el papel que desarrollarán
dentro de nuestros objetivos. Cabe destacar en primer lugar, que en versiones inferiores a
PDF 1.5 se daba un tratatamiento especial a las llamadas 14 fuentes estándar Type 1. Estas fuentes que se muestran en la Tabla 5.6 disponían de muchas entradas opcionales en
el diccionario de fuente. Sin embargo, en versiones posteriores, se desaprueba esta práctica
y se establece que también estas 14 fuentes deben ajustarse a un objeto fuente completo,
aunque por compatibilidad hacia atrás, se debe permitir un tratamiento especial en las aplicaciones visualizadoras. Es por esto que es posible anular una fuente estándar incluyendo
un diccionario completo e incluso incrustando el programa fuente.
Times Roman
Helvetica
Courier
Symbol
Times-Bold
Helvetica-Bold
Courier-Bold
ZapfDingbats
Times-Italic
Helvetica-Oblique
Courier-Oblique
Times-BoldItalic
Helvetica-BoldOblique
Courier-BoldOblique
Cuadro 5.6: Fuentes Type1 estándar.
Estas fuentes estándar o sus métricas [3] y fuentes adecuadas para sustituirlas, deben estar
disponibles en las aplicaciones usuarias2 .
Las entradas en un diccionario fuente de Type 1 son:
2 Dichas
métricas o Adobe Font Metrics files (AFM) de toda ellas se encuentran disponibles en la página
web de ASN.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
57
Type (tipo nombre, obligatoria).
En el caso que nos ocupa en esta sección (diccionarios fuente), esta entrada contendrá
siempre la palabra Font.
Subtype (tipo nombre, obligatoria).
Tipo de la fuente; en fuentes de tipo Type 1, el valor debe ser Type1. Name (tipo
name, sólo obligatoria en PDF 1.0): Nombre mediante el cual los subdiccionarios de
fuente del actual diccionario de recursos, se referirán a esta fuente. Esta entrada está
obsoleta.
BaseFont (tipo nombre, obligatoria).
Nombre PostScript de la fuente Type1. Entrada clave en la especificación externa
del nombre de la fuente. Se corresponde con el valor de FontName dentro de su
programa fuente asociado. Su uso será fundamental en el desarrollo de este proyecto,
dado que permitirá determinar el nombre de la fuente que se está empleando mediante
un especificador estándar y no mediante especificadores propios de PDF.
FirstChar, LastChar (tipo integer, obligatorios salvo para las 14 fuentes estándar).
Estas entradas se corresponden con los valores de los códigos del primer y último
carácter que se definen en la cadena de anchura o desplazamiento de glifos (Widths).
Widths (tipo cadena o referencia a cadena, obligatorios salvo para las 14 fuentes
estándar).
Cadena de (LastChar-FirstChar+1) elementos, donde cada elemento o anchura se
corresponde a un código de carácter que equivale a FirstChar sumado al índice de
la cadena. Estas anchuras deben ser consistentes con las anchuras de glifo que se
especifican en el programa fuente y están dadas en una unidad tal que 1000 unidades
se corresponden con 1 unidad en el espacio de texto.
FontDescriptor (referencia a tipo diccionario, obligatorio salvo para las 14 fuentes
estándar).
Referencia al FontDescriptor encargado de la descripción de las métricas de la fuente
más allá de las anchuras de glifo.
Encoding (tipo nombre o referencia a diccionario, opcional).
Especificación de la codificación de la fuente si esta es diferente de la codificación
interna de la fuente. Puede ser tanto un nombre predefinido (MacRomanEncoding,
MacExpertEncoding o WinAnsiEncoding) como un diccionario que especifique diferencias respecto de la codificación interna o codificación predefinida. Más adelante se
detallará en profundidad la codificación.
ToUnicode (tipo stream, opcional).
Flujo que contiene un archivo CMap que mapea los códigos de carácter a valores
Unicode.
Un ejemplo de diccionario fuente Type 1, Times New Roman con codificación estándar
WinAnsiEncoding puede ser el siguiente:
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
58
Ejemplo 5.4
98 0 obj
<<
/Type /Font
/Subtype /Type1
/FirstChar 32
/LastChar 103
/Widths [ 250 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 500 500 500 500 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 556 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 444 0 0 0 444 0 500 ]
/Encoding /WinAnsiEncoding
/BaseFont /TimesNewRoman
/FontDescriptor 32 0 R
>>
endobj
Las fuentes MMType 1: Multiple Master Fonts
Las fuentes Multiple Master son una extensión de las fuentes Type1 que permiten generar
una amplia gama de tipos de letra a partir de un único programa fuente. Esto se consigue
gracias a que una fuente particular de tipo MMType 1 se obtiene mediante una instancia con
parámetros dados, es decir, las fuentes MMType1 disponen de un número finito de parámetros numéricos, como son el peso (próximo al concepto de negrita), la anchura (contraída o
expandida) o el tamaño óptico, que deben especificarse para dar lugar a una instancia de
fuente MMType 1, que es simplemente una fuente Type1. En resumen, una fuente Multiple Master da lugar a un rango de fuentes Type1 con la misma base pero con diferencias
significativas que las hacen distintas.
Salvo las siguientes excepciones, el diccionario asociado a una fuente Multiple Master contiene las mismas entradas que las que se han explicado arriba para las fuentes Type1.
Subtype.
El valor de subtipo pasa de ser Type1 a MMType1.
BaseFont.
Dadas las propiedades especiales de las estas fuentes, el nombre PostScript está sujeto a múltiples posibilidades, es decir, en Multiple Master hablamos de instancias y
no de fuentes en si mismas, y es por esto por lo que el nombre de la instancia de
fuente sólo tiene sentido si se encuentra acompañado de los valores de los parámetros que la definen. Existe una convención para incluir dichos parámetros al nombre
PostScript mediante guiones bajos, que se sale fuera de las especificaciones de PDF,
pero que resultan fundamentales para la denominación de estas fuentes en las aplicaciones usuarias. Ejemplos típicos de estas fuentes son MinionMM y MyriadMM. Así,
sus instancias deben determinar en su nombre, el peso, la anchura y el tamaño óptico
o el peso y la anchura respectivamente, como se deduce de estos dos especificadores:
/MinionMM_362_400_10_, /MyriadMM_200_300_.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
59
El ejemplo 5.5 presenta un objeto fuente de tipo MMType1.
Ejemplo 5.5
4 0 obj
<<
/Type /Font
/Subtype /MMType1
/Name /F15
/FirstChar 1
/LastChar 255
/Widths 21 0 R
/Encoding 409 0 R
/BaseFont /MinionMM_450_520_8_
/FontDescriptor 119 0 R
>>
endobj
5.6.2.
Las fuentes True Type
Las fuentes True Type constituyen actualmente el formato oficial de fuente de Microsoft
Windows Operating System y fueron desarrolladas por Apple Computer, Inc.
El diccionario fuente asociado a estas fuentes True Type, puede contener las mismas entradas
que un diccionario Type 1 con las siguientes salvedades:
Subtype.
El valor asociado como es lógico, es TrueType.
BaseFont.
El valor de BaseFont para fuentes True Type, puede ser determinado por la aplicación
generadora de PDF siguiendo dos procedimientos distintos. La primera de ellas consiste
en emplear el nombre PostScript que aparece en la tabla "name" dentro de una fuente
de tipo True Type, mientras que la segunda de ellas consiste, ante la ausencia de esta
tabla, en emplear el nombre con el que es conocida la fuente en el sistema operativo en
que se está generando o modificando el PDF, eliminado todos los caracteres en blanco
que pudiesen encontrarse en dicho especificador.
Cuando se hace uso de una característica complementaria de una fuente, es decir, la fuente
es una variante de su fuente base al ser negrita o cursiva, el nombre de la ésta se acompaña
separado por comas de la característica diferenciadora. Una valor válido para la entrada
BaseFont para una fuente Times de tipo True Type y negrita, sería /Times,Bold. Como
ejemplo de objeto fuente para el tipo True Type, se presenta el ejemplo 5.6.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
60
Ejemplo 5.6
139 0 obj
<<
/Type/Font
/Subtype/TrueType
/FontDescriptor 143 0 R
/LastChar 225
/Widths 7 0 R
/BaseFont/Times,Bold
/FirstChar 32
/Encoding/WinAnsiEncoding
>>
endobj
5.6.3.
Los subconjuntos de fuentes o font subsets
Desde la versión PDF 1.1, se permite la posibilidad de incluir subconjuntos de fuentes Type1 y
True Type dentro del propio fichero. Es decir, se admite la opción de incrustar el subconjunto
de caracteres que se emplea en algún o varios textos del PDF, consiguiendo aprovechar las
numerosas ventajas de la incrustación pero reduciendo al máximo el tamaño del archivo,
lo que sin duda pude considerarse como uno de los handicaps mayores de dicha técnica.
Para definir este tipo de fuentes sólo es necesario incluir unos leves cambios en el objeto
fuente y en el font descriptor, y éstos permiten a una aplicación determinada, reconocerlas
y combinar documentos que empleen distintos subconjuntos de una misma fuente.
El nombre con el que se define un subconjunto de fuente y que se sigue tanto en la entrada
BaseFont de los objetos fuente como en la entrada FontName de los font descriptors,
que se estudiarán más adelante, se sigue el siguiente patrón: Etiqueta–signo más–Nombre
PostScript. Esto es, una etiqueta formada por un conjunto arbitrario pero distinto para cada
subconjunto de una misma fuente, de seis letras mayúsculas seguidas de un signo más y del
nombre PostScript. Un ejemplo de entrada de un subconjunto de la fuente BookAntiqua
podría ser: /BaseFont/GEHDNE+BookAntiqua.
5.6.4.
Las fuentes Type 3
Las fuentes Type 3 se distinguen especialmente de todas las soportadas por PDF. Hasta
el momento, se ha considerado de forma general para todas las fuentes, que un diccionario
fuente contenía información de éstas y hacía referencia a un programa fuente donde se
describían los glifos. Sin embargo, en las fuentes Type 3 el diccionario describe la fuente.
Los glifos se definen mediante flujos de operadores gráficos de PDF, que se asocian con sus
respectivos códigos de carácter mediante una nueva entrada de codificación que se encarga
de dicha asociación, es decir, se encarga de relacionar los códigos de carácter con los nombres
de carácter para cada glifo.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
61
Como ventaja fundamental de este tipo de fuentes, se destaca su flexibilidad frente otros
tipos como Type1, dado que cada glifo puede componerse de una secuencia arbitraria de
operadores gráficos PDF. Sin embargo, este tipo de fuentes no provee mecanismos para
mejorar los resultados o salidas en caso de fuentes de pequeños tamaños o bajas resoluciones,
que por ejemplo si se preve en el caso de las fuentes Type 1.
A continuación, vamos a listar las entradas en el diccionario fuente de las fuentes Type 3 que
difieren sobre las analizadas en las fuentes Type1 de forma significativa o que son específicas
para estas fuentes.
Subtype.
En este caso el valor debe ser Type 3.
FontBBox (tipo rectángulo, obligatoria).
Definición de font bounding box o mínimo rectángulo capaz de contener todas los glifos
de la fuente situados con sus orígenes coincidentes.
FontMatrix (tipo array, obligatoria).
Cadena de seis cifras que especifica la matriz de fuente, mapeando el espacio de glifo
al espacio de texto.
CharProcs (tipo diccionario, obligatoria).
Cada clave de este diccionario se corresponde con un nombre de carácter y el valor
asociado identifica el flujo de operadores gráficos que son los encargados de construir
y representar el glifo correspondiente.
Encoding (tipo nombre o diccionario, obligatoria).
Un diccionario de codificación que especifica mediante su cadena Differences la codificación completa de la fuente que se trata. Se detalla esta entrada en la sección 5.6.5.
Resources (tipo diccionario, opcional pero altamente recomendada).
Lista de los recursos (fuentes o imágenes) que se requieren para la descripción de los
glifos de esta fuente. Si se requieren recursos que no se especifican en este diccionario,
éstos han de leerse del diccionario de recursos de página que está haciendo uso de la
fuente.
Dada la especial naturaleza de estas fuentes, es necesario analizar de forma independiente
su proceso de decodificación en el Showing Text. Para cada código de carácter de una fuente
Type 3 que se está empleando, una aplicación debe realizar los siguientes pasos para representar gráficamente un resultado.
1. Se localiza el código de carácter en la entrada de codificación de la fuente o Encoding,
para obtener un nombre de carácter.
2. Una vez se tiene el nombre del carácter, se busca éste en el diccionario asociado a
CharProcs para conseguir el stream object u objeto de flujo capaz de describir el
glifo.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
62
3. Se procede a invocar la descripción de glifo en el stream object 3 .
En la descripción de glifo o invocación del stream de glifo se deben ejecutar uno de los operadores d0 o d1 que se detallan abajo, para aportar información de anchura o desplazamiento
de glifo y de dimensiones de bounding box al proceso de representación de fuentes, y deben
siempre preceder cualquier otra ejecución de otro tipo de operadores como los path-painting
operators que también forman parte de la descripción de glifo. Estos operadores básicos de
las fuentes de Type 3 son:
Operador d0: Establece información de anchura del glifo y determina se la descripción
de glifo especifica tanto su forma como su color. Este operador sólo se permite dentro
de un flujo o stream que se contemple en un diccionario CharProcs de una fuente
Type 3. Suele emplearse únicamente si la descripción de glifo incluye el color.
Operador d1: Establece información de anchura de glifo y de las dimensiones de contorno o bounding box del glifo, y especifica que la descripción de glifo no especifica el
color sino sólo la forma. Este operador, al igual que el anterior, sólo se permite dentro
de un flujo indicado en el diccionario CharProcs de la fuente.
Como muestra del uso de este tipo de fuentes, se presenta el ejemplo 5.7. Se trata de una
fuente con sólo dos glifos (rectángulo y cuadrados rellenos).
3 El estado gráfico se almacena antes de esta invocación y se restaura posteriormente, por esto los cambios
en el estado gráfico que se generen con esta ejecución no perdurarán una vez finalizado el proceso. Es
importante esta matización porque las descripciones de glifo en el flujo pueden requerir operaciones que
alteren dicho estado, pero en ningún caso deben mantenerse una vez finalizadas éstas.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
Ejemplo 5.7
4 0 obj % Objeto fuente de una fuente Type3
<<
/Type /Font
/Subtype /Type3
/FontBBox [ 0 0 750 750 ]
/FontMatrix [ 0.001 0 0 0.001 0 0 ]
/CharProcs 10 0 R % Esta entrada hace referencia a los streams de definición de stream
/Encoding 9 0 R % Esta entrada nos conduce al diccionario de codificación
/FirstChar 97
/LastChar 98
/Widths [ 1000 1000 ]
>>
endobj
9 0 obj % Diccionario de codificación
<<
/Type /Encoding
/Differences [ 97 /cuadrado /triángulo ]
>>
endobj
10 0 obj
<<
/cuadrado 11 0 R % referencia al stream de definición del glifo square
/rectangulo 12 0 R % referencia al stream de definición del glifo triangle
>>
endobj
11 0 obj % Stream de definición del glifo cuadrado
< </Length 39 > >
stream
1000 0 0 0 750 750 d1 % operadores d1 y d0 siempre preceden la descripción de glifo
0 0 750 750 ref
endstream
endobj
12 0 obj % Stream de definición del glifo triángulo
< </Length 48 > >
stream 1000 0 0 0 750 750 d1
0 0 m 375 750 l 750 0 lf
endstream
endobj
63
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
64
La salida de un cadena que contiene ababab empleando esta fuente se muestra en la figura
5.3 junto con una cadena en un plano posterior mostrando la misma cadena utilizando Arial.
Figura 5.3: Utilización de fuentes Type 3
Como se verifica con esta breve introducción a las fuentes Type 3, su naturaleza es intrínsecamente incrustada, es decir, las fuentes Type 3 no hacen referencia a recursos externos
al propio fichero PDF. Pese a las diferencias notables con las fuentes incrustadas tal y como las conocemos (programa fuente incrustado o incorporado en el archivo PDF) podemos
considerarlas como fuentes autónomas en cuanto a disponibilidad de recursos en el sistema
huésped, y por lo tanto, no tiene ninguna lógica tratar o analizar la posible incrustación
de este tipo de fuentes en PDF, dado que como se insiste, su carácter ya es incrustado por
si mismo. Dicho esto y dado el objeto de este proyecto, se entiende que no se detallen en
demasía las cuestiones relacionadas con este tipo de fuentes.
5.6.5.
Codificación de caracteres
Vamos a tratar en esta sección la codificación de fuentes simples en PDF. La codificación
de fuentes se define como la asociación entre los códigos de carácter que se emplean en una
cadena de texto y las descripciones de glifo.
Cada programa fuente, excepto en el caso de las fuentes Type3, tiene una codificación propia
o built-in. Sin embargo, para adecuarse a las características de la aplicación o sistema que
representa el texto a mostrar, un diccionario de fuentes PDF puede alterar esta codificación.
De esta manera, mediante la flexibilidad en la codificación de caracteres, se consiguen dos
propiedades de gran valor. Por un lado, se permite representar texto que está codificado
en cualquiera de las múltiples fórmulas convencionales. Por ejemplo, los sistemas operativos
Microsoft Windows y Apple Mac OS emplean distintas codificaciones estándares para textos
latinos, y gracias a la flexibilidad en la codificación, todas ellas pueden utilizarse mediante
la alteración oportuna en el diccionario de fuentes PDF. Además, se permite la creación de
diferentes codificaciones según el subconjunto de la fuente que se emplea. Así, las aplicaciones
pueden determinar la codificación de forma customizada, pudiéndose por tanto, extraer de
una misma secuencia de códigos, distintos conjuntos de caracteres según la codificación
personalizada que se especifica en el diccionario de la fuente .
Entre las codificaciones de programas fuente para textos latinos de Adobe System, podemos
encontrar las siguientes;
StandardEncoding o codificación por defecto de Adobe.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
65
WinAnsiEncoding y MacRomanEncoding. Para los sistemas operativos Windows y Mac OS
se tienen las codificaciones WinAnsiEncoding y MacRomanEncoding, respectivamente.
MacExpertEncoding. La codificación MacExpertEncoding se emplea para fuentes que contienen caracteres especiales en tipografías sofisticadas.
Las fuentes en PDF pueden clasificarse en dos grandes grupos, simbólicos y no simbólicos.
Las fuentes no simbólicas son aquéllas que se ajustan al conjunto de caracteres estándares
latinos de Adobe, constituyendo las simbólicas aquéllas que contienen otros conjuntos de
caracteres cuyas codificaciones no se ajustan a las que acabamos de mencionar, dado que
disponen de codificaciones built-in o propias de cada fuente. Entre las fuentes estándares de
Adobe, tenemos dos ejemplos de fuentes simbólicas: Symbol y ZapfDingbats.
Como se ha introducido arriba, la codificación propia o built-in de un programa fuente puede
ser alterada mediante la modificación del diccionario fuente PDF, y más en concreto con la
entrada Encoding. El valor de esta entrada puede ser una de las codificaciones estándares
que ya se han señalado (MacRomanEncoding, MacExpertEncoding, o WinAnsiEncoding) o
también un diccionario de codificación o Encoding dictionary. Como es lógico, la ausencia de
esta entrada implicará la no modificación de la codificación respecto del programa fuente.
A continuación, vamos a analizar las distintas entradas que se encuentran en un diccionario
de codificación o Encoding dictionary, dado que es fundamental para la incrustación de
fuentes con codificaciones customizadas conocer dichos campos, como se apreciará en la
sección de desarrollo de este proyecto.
Type (tipo nombre, opcional).
En este caso el tipo de diccionario será de codificación y esta entrada consiguientemente
es Encoding.
BaseEncoding (tipo nombre, opcional).
Nombre predefinido de codificación empleada entre las estándares, es decir, MacRomanEncoding, MacExpertEncoding, o WinAnsiEncoding sobre la que se aplica
la cadena de diferencias Differences que se explica abajo, si esta se encuentra presente.
Si esta entrada se encontrara ausente, Differences se aplicaría sobre las codificación
estándar de la fuente, esto es, StandardEncoding o built-in según se trate o no de
una fuente simbólica.
Differences (array, opcional y no recomendada para fuentes de tipo True Type).
Cadena que describe las diferencias respecto a la codificación señalada en BaseEncoding, ya sea esta codificación una de las estándar o codificación implícita. Esta
cadena Differences es una estructura formada por códigos de caracteres seguidos de
sus nombre de carácter. Si se va a modificar una secuencia de códigos es preferible
especificar un sólo código y varios nombres, sin determinar el código explícitamente,
dado que se entiende que la posición de un nombre en la cadena conforma el incremento del valor de su código respecto del código de inicio de secuencia. Esta manera
de presentar los códigos, un sólo código y varios nombres de caracteres, puede emplearse cuantas veces sea conveniente en la cadena Differences. De forma gráfica,
esta estructura se representa:
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
66
[código 1 nombre_caracter1,1 nombre_caracter1,2...
código 2 nombre_caracter2,1 nombre_caracter2,2 ...
...
código n nombre_caractern,1 nombre_caractern,2]
Abajo se muestra un caso particular de una estructura de codificación customizada de una
fuente partiendo de una codificación implícita (no se modifica ninguna de las tres codificaciones estándar que se presentan en la entrada BaseEncoding). Así, el código para el
nombre de carácter ”space” se corresponde con el 32 y para el carácter de exclamación o
”exclam” estaría codificado con el 33.
Ejemplo 5.8
2 0 obj
< </Type/Encoding
/Differences[32/space/exclam/quotedbl/numbersign/dollar/percent
/ampersand/quotesingle/parenleft/parenright/asterisk/plus/comma
/minus/period/slash/zero/one/two/three/four/five/six/seven/eight
/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E
/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash
/bracketright/asciicircum/underscore/grave/a/b/c/d/e/f/g/h/i/j
/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
128/Euro
130/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl
/circumflex/perthousand/Scaron/guilsinglleft/OE
159/Ydieresis/space/exclamdown/cent/sterling/currency/yen/brokenbar
/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
/guillemotright/onequarter/onehalf/threequarters/questiondown
/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
]> >endobj
Por convención, se puede emplear el nombre .notdef para indicar que no se asocia ningún
nombre de carácter a dicho código y que su valor será el valor por defecto que deba aplicársele.
El proceso de interacción entre el diccionario de codificación y las estructuras internas de
codificación de las fuentes simples Type 1, Type 3 y True Type se detalla brevemente en las
siguientes dos secciones.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
67
Codificación de las fuentes Type 1
En las fuentes Type 1 la codificación intrínseca o built-in se especifica mediante una cadena
Encoding que forma parte de su programa fuente y que no debe ser confundida con el
diccionario Encoding, entrada en un diccionario de fuente. En esta cadena, las descripciones
de glifo se encuentran indexadas por nombres y no por códigos. De forma general, estos
nombres de carácter son objetos nombre PDF. En el caso de los caracteres latinos, se asocian
dichos caracteres con letras simples, es decir, una "A" o "a". Sin embargo, para otros tipos de
caracteres, como las exclamaciones, ampersand, etc. se emplean nombres compuestos como
"exclam" o "parenleft".
Todos los programas fuente Type 1 contienen un glifo denominado .notdef. El efecto de la
representación de este carácter depende del diseñador de la fuente, que en el caso de las
fuentes de este tipo creadas por Adobe, consiste en un espacio en blanco. Éste se emplea
en el caso de que un diccionario de codificación PDF haga referencia a un nombre de glifo
que no se encuentra en el programa fuente o cuando se desea que un determinado código
se represente con el valor por defecto o .notdef del programa fuente. Como se ha explicado
arriba de forma general, la entrada de diccionario de codificación o Encoding entry puede
alterar de forma personalizada este mapeo de códigos de carácter a nombres de caracteres
en las fuentes Type 1, ya sea partiendo de la codificación built-in de la fuente o de la que
se especifique en BaseEncoding. Esto es, la cadena Differences puede mapear cualquier
código a nombre de glifo siempre que éste se encuentre presente en el programa fuente,
aplicándose el especificador .notdef en caso contrario.
Codificación en las fuentes Type 3
Las fuentes Type 3 son fuentes que como se ha señalado anteriormente, son autocontenidas,
es decir, contienen toda la información relacionada con ellas dentro de sus propias estructuras
y no necesitan recurrir a ningún diccionario fuente. Así las descripciones de glifo aparecen
de forma explícita en su diccionario CharProcs y al igual que en el caso de las fuentes
Type 1, se encuentran indexados por nombres y no por códigos. A su vez, la codificación
se encuentra también completamente definida en la entrada Encoding de su diccionario de
fuente, que en este tipo resulta de presencia obligatoria en dicho diccionario.
Codificación en las fuentes True Type
En el caso de las fuentes True Type, el mapeo de códigos a descripción de glifos se realiza de
forma directa, sin necesidad de empleo de nombres, haciendo uso de la estructura interna al
programa fuente llamada "cmap", que no debe confundirse con la estructura CMap de las
fuentes compuestas que se introducirán más adelante.
La entrada de codificación de un diccionario fuente junto con esta estructura "cmap", permiten la obtención de las descripciones de glifo. La tabla "cmap" contiene una o varias subtablas que representan distintas codificaciones para las diferentes plataformas, como Mac
OS o Windows. Cada subtabla se distingue por dos índices, identificador de plataforma
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
68
e identificador de codificación específica de la plataforma. Así por ejemplo, la dupla (3,1)
puede referirse a un sistema operativo Windows con una codificación específica Microsoft
Unicode.
Por otra parte, es posible, aunque no es obligatorio, que un programa fuente True Type
contenga una tabla llamada "post" que permite la indexación de caracteres mediante nombres
de glifos, como en el caso de las fuentes Type 1. De esta forma, si una aplicación necesita
emplear una codificación mediante nombres de glifos, se procede primero a traducir los
nombres de los glifos a códigos en una de las codificaciones que permite "cmap" o, en el caso
de que esta correspondencia no sea posible, se traduce directamente mediante la tabla "post"
de nombre de glifo a descripción de glifo. Dado que algunos aspectos de la selección de glifo
en las fuentes True Type, dependen directamente de la plataforma o sistema operativo host,
se insiste en las especificaciones de PDF 1.7, en la necesidad lógica de la incrustación de este
tipo de fuentes junto con otras múltiples restricciones en las codificaciones customizadas de
éstas. Es por esto por lo que se declara que la cadena Differences en un diccionario de
codificación, no es recomendable en el caso de las fuentes True Type.
Un visualizador realiza los siguientes pasos para la decodificación de caracteres de una fuente
True Type. Si la codificación se corresponde con una de las codificaciones estándar, como
MacRomanEncoding o WinAnsiEncoding, el visualizador genera una tabla de codificación
de mapeo de códigos de carácter a nombre de glifos, inicializada con los valores estándar de
dichas codificaciones. En el caso de que la codificación se corresponda con un diccionario de
codificación, dicha tabla se inicializa con los valores de la entrada BaseEncoding de dicho
diccionario, y se modifica con la cadena Differences si ésta se encuentra presente.
Después de la inicialización, si existe una subtabla de cmap (3,1) o subtabla de Microsoft
Unicode:
Cada código de carácter se mapea en un nombre de glifo, empleando la tabla inicializada que se ha presentado arriba.
El nombre de glifo se mapea en un valor Unicode mediante la consulta de la lista Adobe
Glyph List.
Por último, este valor Unicode se traduce a descripción de glifo mediante la subtabla
”cmap” (3,1).
Si la subtabla (3,1) no se encuentra presente pero si existe una (1,0) o subtabla Macintosh
Roman:
Cada código de carácter se mapea en un nombre de glifo empleando la tabla inicializada, al igual que en el primer paso del caso anterior.
El nombre de glifo se mapea de nuevo a código de carácter, siguiendo las reglas de
codificación estándar Roman en Mac OS.
Finalmente, dicho código se mapea a descripción de glifo siguiendo la tabla (1,0).
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
69
En cualquiera de los casos anteriores, si el nombre de glifo no se puede mapear como se ha
explicado, se recurre a la tabla de traducción directa de nombre de glifo a descripción de
glifo "post", siempre y cuando ésta exista.
Para el caso de fuentes que no contienen una entrada de codificación en su diccionario como
en los casos anteriores, se emplean, en este orden, la subtabla (3,0) si el programa fuente la
contiene, o la (1,0) si se encuentra presente. Para poder emplear las primera de las tablas,
es necesario que los códigos se encuentren dentro de los rangos 0x0000 - 0x00FF, 0xF000 0xF0FF, 0xF100 - 0xF1FF, o 0xF200 - 0xF2FF. Si se halla en uno de estos rangos, conforma
un código de carácter de dos bytes. Si se emplea la segunda de las tablas, la cadena será
interpretada por códigos de carácter formados por un sólo octeto.
En caso de que el carácter no pueda ser mapeado de ninguna de estas formas, los resultados
dependerán de la implementación en concreto.
5.7.
Las fuentes compuestas
Las fuentes compuestas o fuentes Type 0, son aquéllas que necesitan de un objeto fuente auxiliar de donde obtener las descripciones de glifo y que se denominan fuentes CID o CIDFonts.
Las fuentes Type 0 son llamadas fuentes raíz, frente a las fuentes CID, que son llamadas
descendientes de estas primeras. En PDF una fuente compuesta se representa mediante un
objeto fuente cuyo valor de subtipo es Type0 y la acción de los operadores de showingtext presenta un comportamiento distinto respecto del que tiene ante una fuente simple.
Para una fuente simple, cada byte de una cadena a representar se corresponde con un glifo
en su programa fuente, mientras que para las fuentes compuestas, un byte o una secuencia
de bytes seleccionan un glifo de su fuente descendiente. Esta propiedad de las fuentes compuestas permite el uso de conjuntos de caracteres muy extensos, como contemplan lenguajes
como el chino, el japonés o el coreano, además de simplificar la organización de fuentes que
tienen requerimientos complejos de codificación.
En PDF, las fuentes Type 0 necesitan de tres elementos básicos para su funcionamiento:
1. Objeto fuente raíz de subtipo Type0
2. Objeto fuente descendiente de la anterior o CIDFont
3. Diccionario CMap para la codificación de los caracteres
Al diferencia del lenguaje PostScript, en PDF sólo se permite que una fuente raíz contenga
un descendiente y la codificación de caracteres sólo puede realizarse mediante el uso de diccionarios CMap, que constituye uno de los múltiples procedimientos que admite PostScript.
Las fuentes CID-keyed fonts son las únicas fuentes compuestas que se permiten en PDF,
y su uso resulta de la combinación, que se realiza a través del diccionario Type 0, de los
objetos CIDFont y CMap. Así, mediante dichos objetos, los glifos de una fuente Type0-CIDkeyed pueden ser seleccionados del texto que se desea mostrar mediante códigos de longitud
variable.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
70
En esta sección se va a introducir la arquitectura de las fuentes CID-keyed para, seguidamente, presentar los componentes equivalentes a dichas fuentes compuestas dentro de un
fichero PDF, es decir, los objetos de tipo Type0, CIDFont y CMap.
5.7.1.
Arquitectura de las fuentes CID-keyed.
Las fuentes CID-keyed constituyen una forma eficiente de definir codificaciones de carácter de
múltiples bytes, fuentes compuestas de una gran cantidad de glifos y fuentes que incorporan
glifos de otras fuentes. Como se ha señalado arriba, para textos escritos en lenguajes como
el chino, japonés o coreano (CJK), que abarcan un conjunto numeroso de caracteres, esta
características de las fuentes CID-Keyed proporcionan una gran flexibilidad que resulta
fundamental en este tipo de sistemas de escritura.
En estas fuentes, las descripciones de glifos se indexan y son accedidas mediante los identificadores de carácter o números CID (character identifier) y de ahí el nombre de dichas
fuentes compuestas. Esta forma de selección es mucho más eficiente para fuentes con un
gran conjunto de caracteres que el acceso por nombre que emplean algunas fuentes simples,
como se ha explicado en la sección anterior. El rango de identificadores varía de 0 a un valor
máximo dependiente de la aplicación.
Una colección de caracteres se define como un conjunto ordenado de glifos que se necesitan
para soportar uno o más conjuntos de caracteres populares de un lenguaje determinado. El
orden de los glifos en dicha colección determina el número CID o identificador de carácter
para cada glifo, siendo necesario que cada fuente CID-Keyed referencie de forma explícita
la colección de caracteres en que basa su numeración.
Un archivo de mapa de caracteres o archivo CMap es el encargado de establecer la correspondencia entre los códigos de carácter y los números CID de identificación de glifos,
acercándose pues, al concepto de codificación de carácter que presentábamos en las fuentes
simples. Sin embargo, mientras que de forma general, en las fuentes simples se permite un
limite de 256 glifos para ser codificados y accedidos en un determinado instante, gracias a
los CMap, las fuentes compuestas CID-Keyed pueden realizar una correspondencia código a
glifo con longitud de códigos de múltiples bytes, que son capaces de señalar los miles de glifos
que pueden presentarse en una fuente extensa. Un ejemplo se encuentra en la codificación
ampliamente utilizada en japonés Shift-JIS.
Así, un mapa de caracteres puede referenciar una colección de caracteres entera, un subconjunto, varias colecciones de caracteres e incluso, a otro CMap sin necesidad de dúplica. Para
esto es necesario que el CMap contemple dos números de identificación:
1. Font number o número de fuente, el cual en PDF siempre se tendrá el valor 0.
2. Character selector o selector de carácter, su valor en PDF será siempre el número CID.
Un archivo CIDFont contiene las descripciones de glifo para una colección de caracteres
dada, las cuales suelen representarse en un formato parecido al que se emplea en la fuentes
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
71
simples, como Type 1 o True Type, con la diferencia de la identificación (en este caso los
glifos se identifican mediante los números CID y no por nombres) y de la organización.
Una vez que se han introducido los componentes de las fuentes CID-Keyed, se indican sus
implementaciones concretas en PDF, es decir, los objetos en que se plasman en este lenguaje.
Los programas CMap y CIDFont se presentan en forma de objetos de flujo o referenciados
como archivos externos al propio fichero PDF, (se detallarán en las secciones siguientes) que
se combinan para dar lugar a una fuente CID-Keyed representada mediante una fuente Type
0. En resumen, el objeto fuente Type 0 contiene dos entradas, /Encoding y /Descendantsfonts que referencian a un CMap y un CIDFont respectivamente, y que constituyen
la implementación de este tipo de fuentes en PDF.
5.7.2.
Los diccionarios CIDSystemInfo
Tanto los diccionarios CIDFont como los CMap, presentan en su estructura una entrada (/CIDSystemInfo) que especifica la colección de caracteres que ambos diccionarios
asumen. Es decir, la interpretación de los números CID de CMap que usa el objeto CIDFont. Las entradas en este objeto se señalan a continuación junto con una breve descripción.
Registry (tipo cadena ASCII, obligatorio).
Cadena que identifica el emisor de la colección de caracteres, por ejemplo Adobe.
Ordering (tipo cadena ASCII,obligatorio).
Cadena que da nombre único a la colección dentro dentro del campo anterior, por
ejemplo Japan1.
Supplement (tipo entero, obligatorio)
Número de suplemento de la colección de caracteres. Si una colección original tiene
siempre un número de suplemento 0, a medida que se le añaden adicionales identificadores de carácter o CID dicho suplemento se incrementa.
5.7.3.
Los objetos CIDFonts
Una fuente CIDFont como se ha introducido anteriormente, contiene descripciones de glifo
a las que se accede usando CID como selectores de caracteres. Dentro de estas distinguimos
a su vez dos tipos de fuentes:
Type 0 CIDFont 4 cuyas descripciones de glifo están basadas en el formato Adobe Type
1.
Type 2 CIDFont que contiene descripciones de glifo basadas en el formato True Type.
4 Es
importante resaltar que la denominación Type 0 tiene un significado completamente distinto cuando
se aplica a un objeto fuente y cuando se aplica a una fuente CIDFont.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
72
Aunque la entrada Type en un objeto CIDFont tenga un valor Font, no es un objeto
fuente. Un diccionario CIDFont es un objeto PDF que contiene información de un programa
CIDFont. Si se analizan las características de este tipo de objetos frente a las de un objeto
fuente en sentido estricto, se aprecia que en su diccionario no se encuentra una entrada
Encoding5 , no se puede listar en un diccionario de recursos y no se puede emplear como
parámetro del operador Tf. Sólo se emplea como descendiente de una fuente Type 0.
Se presentan a continuación las entradas en objeto CIDFont:
Type (tipo nombre, obligatorio).
Aún teniendo en cuenta sus características especiales, su tipo es Font.
Subtype (tipo nombre, obligatorio ).
Como se acaba de señalar arriba, el tipo de fuentes dentro de CIDFont son dos y
sus correspondientes subtipos deben especificarse con los nombres; CIDFontType0
o CIDFontType2.
BaseFont (tipo nombre, obligatorio)
El nombre PostScript del CIDFont. En el caso de las fuentes Type 0 CIDFont, este
nombre coincidirá con la entrada CIDFontName6 en el programa CIDFont. Sin embargo, en el caso de las fuentes Type 2 CIDFont, su nombre se obtiene siguiendo las
mismas convenciones de las fuentes simples True Type en las que se basa. También
puede referirse a nombres de subconjuntos de fuentes que se explican en la sección de
fuentes simples.
FontDescriptor (tipo diccionario, obligatorio).
Diccionario de descripción de métricas adicionales a la anchura o desplazamiento de
glifo de la fuente CIDFont.
CIDSystemInfo (tipo diccionario, obligatorio).
Diccionario de especificación de la colección de caracteres.
DW (tipo entero, opcional).
Anchuras por defecto de glifos de la fuente.
W (tipo cadena, opcional).
Descripción de las anchuras de glifo o desplazamiento de glifo de la fuente.
DW2 (tipo cadena, opcional con aplicación sólo en la fuentes de escritura vertical).
Conjunto de dos números que especifican las métricas por defecto en la escritura vertical.
W2 (tipo cadena, opcional con aplicación sólo en las fuentes de escritura vertical).
Descripción de las métricas para las fuentes de escritura vertical.
5 El diccionario CMap es el encargado en este tipo de fuentes, de especificar la codificación que mapea
códigos de carácter a sus correspondientes CIDs o identificadores de carácter.
6 Nombre de tipo PostScript.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
73
CIDToGIDMap (tipo stream o nombre, opcional con aplicación en las fuentes Type
2 CIDFonts).
Especificación del mapeo de códigos de carácter o CID a índices de glifo. Si el valor de
tipo es stream, será este flujo de bytes el que contenga el mapeo de CIDs a índices de
glifo. En caso contrario, el valor de este campo debe ser Identity, es decir, el mapeo
de CIDs a índices de glifos se realiza mediante la identidad.
El mapeo de descripciones de glifos a identificadores de carácter7 puede ser diferente en cada
descendiente de Type 0. Así, es importante destacar que los procesos de selección de glifos
en las fuentes CIDFont Type 0 y CIDFont Type 2 son completamente distintos, a pesar de
tratarse ambas de fuentes CID.
5.7.4.
Los diccionarios CMaps
Los objetos CMap determinan el mapeo de códigos de carácter a selectores de carácter,
selectores que en el caso de las fuentes CIDFont en PDF, son siempre CIDs. Se puede decir
entonces que un CMap realiza una función análoga a los diccionarios de codificación en las
fuentes simples. Sin embargo, un objeto CMap no hace referencia directamente a una fuente
CIDFont determinada, sino que se combina con dicha fuente para formar parte de una fuente
CID-Keyed, en forma de diccionario de fuente Type0. De esta forma, en el caso de PDF,
todos los mapeos de CMap8 se realizan referenciando a una fuente CIDFont con un número
de fuente o font number que siempre tiene un valor 0.
Además de la función de conversión, CMap determina el modo de escritura (horizontal o
vertical) para todas las fuentes CIDFont con las que se combine. Esta especificación de
modo de escritura resulta fundamental, dado que en la mayoría de las ocasiones este modo
determina las métricas a emplear para la fuente. Por otro lado, hay que señalar que las
variantes en modo de una fuente pueden alterar el CID para un mismo código de carácter.
Los CMap pueden encontrarse en un PDF de dos formas:
Como un objeto de tipo nombre que especifica un CMap predefinido y cuya estructura
y contenido es conocido por la aplicación usuaria.
Como objeto de flujo o stream que contiene un archivo CMap en su interior.
Los archivos CMap predefinidos
A continuación se van a introducir únicamente las dos codificaciones genéricas que se emplean
y cuyo uso es el más extendido. En cualquier caso, aquéllas cuyo nombre finaliza en H
especifican modo de escritura horizontal, y vertical cuando este termina en V.
7 No
se profundiza en este aspecto al considerarse fuera del objeto de este proyecto.
PDF existen otro tipo especial de CMap para la conversión de códigos de caracteres a caracteres
Unicode que no se trata en esta sección.
8 En
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
74
Identity-H: Mapeo con carácter de identidad para los CIDs de dos bytes. Finaliza
con la letra H, indicando el modo de escritura horizontal. Se realiza la conversión de
códigos de carácter, en el rango de 0 a 65535, a los mismos valores CID de dos bytes.
Identity-V: Versión vertical de Identity-H.
Estos CMaps con carácter de identidad se emplean cuando se desean traducir los glifos
a CIDs de forma directa desde la cadena de texto de donde se extraen. Así, cuando una
fuente Type 0 presenta una entrada de codificación con algunos de estos dos valores, la
cadena de texto a representar se interpreta como pares de bytes que conforman CIDs y este
procedimiento es válido para cualquier fuente CIDFont, independientemente de la colección
de caracteres que se maneje.
Los archivos CMap incrustados
Cuando la codificación de los caracteres no se corresponde con ninguna de las predefinidas, el
fichero PDF debe contener un flujo que defina el CMap. Para esto un CMap deberá contener
entradas adicionales que se presentan abajo:
Type (tipo nombre, obligatorio).
Su valor debe ser CMap, pese a que su valor se corresponda con una entrada de
Encoding en la fuente Type0.
CMapName (tipo nombre, obligatorio).
Nombre PostScript de CMap. Debe ser coincidente con el nombre en CMapName en
el fichero incrustado CMap.
CIDSystemInfo (tipo diccionario, obligatorio).
Diccionario de definición de la colección de caracteres para la fuente CIDFont asociada
con el CMap.
WMode (tipo entero, opcional).
Determinación del modo de escritura de las fuentes CIDFonts que se relaciona con el
CMap. Toma valor 0 para modo de escritura horizontal y 1 para modo de escritura
vertical.
UseCMap (tipo nombre o flujo, opcional).
Nombre de un CMap predefinido o flujo contenedor de un CMap que se emplea como
base del mapa de caracteres. Esta entrada permite que el objeto CMap pueda definirse
de forma diferencial con respecto a otro que es conocido9 .
Para estudiar de forma gráfica la estructura de un objeto CMap, veamos el siguiente ejemplo
para una codificación predeterminada japonesa Shift-JIS a la que se le realizan modificaciones mediante un objeto de flujo.
9 Nótese
la similitud con la entrada Differences en los diccionarios de codificación en las fuentes simples.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
Ejemplo 5.9
22 0 obj
< </Type /CMap
/CMapName /90ms−RKSJ−H
/CIDSystemInfo
< </Registry ( Adobe )
/Ordering ( Japan1 )
/Supplement 2 > >
/WMode 0
/Length 23 0 R
>>
stream
/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo
3 dict dup begin
/Registry ( Adobe ) def
/Ordering ( Japan1 ) def
/Supplement 2 def
end def
/CMapName /90ms−RKSJ−H def
/CMapVersion 10 . 001 def
/CMapType 1 def
/UIDOffset 950 def
/XUID [ 1 10 25343 ] def
/WMode 0 def
4 begincodespacerange
<00 ><80 >
<8140 ><9FFC >
<A0 ><DF >
<E040 ><FCFC >
endcodespacerange
100 begincidrange
<20 ><7D >231
<7E ><7E >631
<8140 ><817E >633
<8180 ><81AC >696
<81B8 ><81BF >741
<81C8 ><81CE >749
...Rangos adicionales...
<FB40 ><FB7E >8518
<FB80 ><FBFC >8581
<FC40 ><FC4B >8706
endcidrange
endcmap
CMapName currentdict /CMap defineresource pop
end
end
% %EOF
endstream
75
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
76
La definición de los operadores que integra el flujo que compone el CMap no se analiza por
no resultar relevante en el desarrollo de este proyecto.
5.7.5.
Los objetos fuente Type0
Analicemos en primer lugar las entradas que encontramos en este tipo de diccionarios fuente.
Type (tipo nombre, obligatorio).
Como en el caso de todas las fuentes, este valor debe ser Font.
Subtype (tipo nombre, obligatorio).
El tipo de fuente debe ser Type0 para las fuentes de tipo Type 0.
BaseFont (tipo nombre, obligatorio).
Dado que no existen programas fuente asociados directamente con fuentes Type 0, este
nombre PostScript resulta en principio arbitrario. Vamos a señalar las convenciones
que se emplean para la máxima compatibilidad con los productos de Acrobat. Si su
fuente CIDFont descendiente se trata de una fuente CIDFont Type 0, este nombre
debe ser la unión de la entrada BaseFont de esta última seguida de un guión y el
nombre dado al objeto CMap en la entrada Encoding que se describe a continuación.
Si resulta ser CIDFont Type2, este nombre será idéntico al especificado en la entrada
BaseFont de ésta CIDFont Type2.
Encoding (tipo nombre o flujo, obligatorio).
El nombre de CMap predefinido o flujo contenedor del CMap.
DescendantFonts (tipo cadena, obligatorio).
Cadena de un elemento que indica el CIDFont descendiente de esta fuente Type 0.
ToUnicode (tipo flujo, opcional).
Flujo que contiene un archivo CMap para el mapeo de códigos de carácter a valores
Unicode.
Veamos un ejemplo de uso de este tipo de fuente.
Ejemplo 5.10
14 0 obj< <
/Type /Font
/Subtype /Type0
/BaseFont /HeiseiMin−W5−90ms−RKSJ−H
/Encoding /90ms−RKSJ−H
/DescendantFonts [ 15 0 R ]
> >endobj
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
77
Proceso de decodificación mediante CMap
En el caso de las fuentes Type 0, la entrada Encoding de su diccionario fuente nos conduce
a un objeto CMap, que determinará cómo deben comportarse los operadores de mostrado
de texto en la interpretación de los bytes de las cadenas que se desean representar. En esta
sección se pretende mostrar una introducción al proceso mediante el cual los caracteres de
un texto son decodificados y traducidos en CIDs, que son los selectores de caracteres en el
caso de PDF.
Los rangos de códigos posibles en CMap10 determinan cuantos bytes componen cada uno
de los caracteres que conforman la cadena de texto. Cada rango se especifica mediante una
pareja de códigos de una longitud particular, que constituyen los extremos de cada rango.
Un código que se extrae de una cadena pertenecerá a un rango si su longitud es coincidente
y además, se encuentra dentro de los límites que fijan dichos extremos. Nunca se producirán
para un mismo código múltiples coincidencias, dado que los rangos no se solapan.
Si suponemos una cadena de códigos que se corresponden con una cadena de texto que
se quiere representar, cada secuencia de uno o más bytes se confronta con el conjunto de
rangos posibles. Primero se confrontaría un byte con todos los rangos de longitud un byte
y si no hubiera coincidencia, se extraería otro byte y se repetiría el proceso. Esta operación
se volvería a producirse con cuantos bytes fueran necesarios y hasta finalizar la cadena de
códigos.
Una vez se tiene el código, se realiza la búsqueda de éste en las listas de códigos CMaps
de esa longitud11 y en caso de no encontrar emparejamiento se le aplicaría el valor que se
determine en las listas de códigos no especificados o listas ”notdef” para obtener un selector
de glifo.
El resultado de esta operación son dos números: el número de fuente y un selector de carácter.
Como se ha dicho con anterioridad, el número de fuente en PDF será siempre 0 y se emplea
como índice en la lista de DescendantsFonts para seleccionar la fuente CIDFont. Por otro
lado, el selector de glifo es siempre un CID que se emplea para seleccionar un glifo de la
fuente CIDFont.
Gestión de caracteres no definidos con CMap
En caso de que la operación estudiada en la sección de arriba no consiguiera la selección de
un glifo, se proveen mecanismos auxiliares.
Si el código CID que se ha obtenido no se corresponde con ningún glifo en la fuente
descendiente CIDFont, se consultan las listas de códigos no definidos o notdef mappings 12 de CMap para obtener un sustituto. Si se encuentra un emparejamiento, se
selecciona un nuevo glifo de la fuente descendiente. En caso de que tampoco existiera
glifo para ese CID, se le asignaría el glifo correspondiente a CID 0 o CID por defecto.
10 Véase ejemplo 5.9. Estos códigos están delimitados por las palabras clave begincodespacerange y
endcodespacerange.
11 Véase ejemplo 5.9. Estas vienen delimitados por las palabras clave beginbfchar, endbfchar, begincidchar, endcidchar y los operadores correspondientes.
12 Téngase en cuenta la analogía del nombre con el mecanismo .notdef de las fuentes simples.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
78
Si no se puede traducir el código de una cadena en un CID mediante los rangos
generales ni por las listas de códigos no definidos, se le asignara, como en el caso
anterior, el valor de CID 0.
En caso de que los códigos presenten valores no válidos (las secuencias de bytes del
texto no se correspondan con ningún rango, por ejemplo) se procede a resetear el
algoritmo de mapeo al punto original de la cadena y encontrar los mejores resultados
parciales:
1. Si el primer byte de la secuencia no se corresponde con el primer byte ningún
rango, se le hace corresponder con el rango de menor y de tamaño más próximo.
2. En otro caso, se van añadiendo bytes al código y se confronta dicho código con los
principios de todos los rangos de igual o mayor tamaño. Si existen varios rangos
con emparejamientos parciales de la misma longitud, se toma el que tenga un
menor valor.
5.8.
Los descriptores de fuente
Un descriptor de fuente tiene como función elemental la especificación de las métricas y otros
atributos de un fuente, simple o CIDFont13 , como un todo, completando las métricas que
se definen para los glifos individuales. Estas métricas constituyen una herramienta esencial
para la elección de fuentes cuando el font program no se encuentra disponible, ya sea para
encontrar una similar o para la síntesis de una fuente que se ajuste a dichas métricas. Además,
el font descriptor se puede emplear para incrustar los programas fuente dentro del fichero
PDF, lo que resulta de gran relevancia para el desarrollo de este proyecto.
Un descriptor de fuente es un diccionario que especifica mediante sus entradas los atributos
de una fuente. Las que se presentan a continuación son comunes para todos los descriptores
de fuente, asociados a fuentes simples y compuestas. Las fuentes compuestas necesitan de
otras entradas adicionales que se detallan más adelante:
Type (tipo nombre, obligatorio).
El valor de este campo debe corresponderse con FontDescriptor en este caso.
FontName (tipo nombre,obligatorio).
Nombre PostScript de la fuente, que debe corresponderse con el campo BaseFont en
la fuente que refiera a este descriptor.
FontFamily (tipo cadena de bytes, opcional).
Familia preferente que debe escogerse para la elección o síntesis de fuente. Así, una
fuente HelveticaBold tendría como valor de este campo Helvetica.
13 Nótese que no se incluye el uso de los descriptores de fuente para las fuentes Type 0, sino para sus
fuentes descendientes o fuentes CIDFonts.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
79
FontStretch (tipo nombre, opcional).
Valor de extensión de la fuente que debe corresponderse con uno de los siguientes valores: UltraCondensed, ExtraCondensed, Condensed, SemiCondensed, Normal, SemiExpanded, Expanded, ExtraExpanded o UltraExpanded.
FontWeight (tipo número, opcional).
Grado de grosor o valor de propiedad de negrita de la fuente. Los valores posibles son
100, 200, 300, 400, 500, 600, 700, 800, o 900, indicando cada uno de estos un grosor
mayor que los que le preceden.
Flags (tipo entero, obligatorio).
Conjunto de banderas indicando ciertas propiedades de la fuente como puede ser su
carácter simbólico o sans serif.
FontBox (tipo rectángulo, obligatorio excepto para fuentes Type 3).
Especificación del bounding box, que determina el menor recuadro que es capaz de
contener cualquier glifo de la fuente si se les hiciese coincidir los orígenes a éstos.
ItalicAngle (tipo número, obligatorio).
Ángulo de inclinación de la fuente. Resulta negativo para las fuentes con inclinación a
derechas como suele ocurrir en la mayoría de las fuentes con carácter cursivo.
Ascent (tipo número, obligatorio excepto para las fuentes Type 3).
Este valor determina la máxima altura de los glifos en esta fuente sobre el baseline,
excluyendo el caso de que éstos se encuentren acentuados.
Descent (tipo número, obligatorio excepto para las fuentes Type 3)
La máxima profundidad de dicha fuente con respecto al baseline. Este valor siempre
es negativo.
Leading (tipo número, opcional).
Espaciamiento entre distintas baselines de líneas consecutivas. Valor por defecto 0.
CapHeight (tipo número, obligatorio para las fuentes latinas excepto par Type 3).
Coordenada vertical de la mayor de las mayúsculas con origen el baseline.
XHeight (tipo número, opcional).
Altura del mayor carácter llano en minúsculas, como por ejemplo la letra x en fuentes
latinas. Valor por defecto 0.
SteamV (tipo número, obligatorio excepto para fuentes Type 3).
Anchura, medida de forma horizontal, del glifo de mayores dimensiones verticales de
la fuente.
SteamH (tipo número, opcional).
Grosor, medido de forma vertical, del glifo con mayores dimensiones horizontales de
la fuente.
AvgWidth (tipo número, opcional).
Valor medio de los glifos de la fuente.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
80
MaxWidth (tipo numero, opcional).
La máxima anchura de los glifos de la fuente.
MissingWidth (tipo número, opcional).
Anchura a emplear para los códigos de carácter que no se especifican el la entrada
Widths del diccionario fuente que lo refiere.
CharSet (tipo cadena ASCII o cadena de bytes, opcional y sólo significativa en el
caso de las fuentes Type 1).
Lista con los nombres de los caracteres que componen una fuente subset. En ausencia
de esta entrada, sólo el formato que se emplea para el nombre de dichas fuentes14 ,
puede indicar que se trata de una fuente subset.
Las siguientes tres entradas son de especial importancia en este proyecto, por lo que se
separan del resto. Todas ellas se corresponden con objetos de flujo que contienen programas fuente, es decir, un programa fuente que se encuentre incrustado contiene una de las
siguientes entradas de forma obligatoria:
FontFile (tipo flujo, carácter opcional).
Flujo que contiene un programa fuente Type 1 incrustado.
FontFile2 (tipo flujo, carácter opcional).
Flujo que contiene en su interior un programa fuente True Type incrustado.
FontFile3 (tipo flujo, carácter opcional).
Al contrario que las dos entradas anteriores, ésta contendrá un programa fuente cuyo
formato no se define por el hecho de encontrarse contenido en esta entrada. En este
caso, el tipo de programa fuente dependerá de la entrada Subtype del objeto fuente
que lo invoque. Así, sólo una de las entradas FontFile, FontFile2 o FontFile3 puede
encontrarse de forma simultánea en un descriptor de fuente.
Ejemplo 5.11
Un ejemplo de descriptor de fuente para una fuente Times no incrustada se tiene en el
ejemplo 5.11
14 Véase
la sección dedicada a este tipo de fuentes.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
81
7 0 obj
<<
/Type /FontDescriptor
/FontName /TimesBold
/Flags 262178
/FontBBox [ −160 −200 1202 801 ]
/MissingWidth 255
/StemV 105
/StemH 45
/CapHeight 660
/XHeight 394
/Ascent 720
/Descent −270
/Leading 83
/MaxWidth 1212
/AvgWidth 478
/ItalicAngle 0
>>
endobj
Entradas opcionales para fuentes CIDFont
Como se señaló en la sección anterior, las fuentes compuestas en PDF, dado su carácter
especial, pueden contener entradas adicionales que se introducen muy brevemente a continuación:
Style (tipo diccionario, opcional).
Diccionario de definición de estilo de fuente. En la actualidad la única entrada que se
encuentra en panose, consistente en una cadena de 12 bytes que define identificadores
normalizados [4, 5].
Lang (tipo nombre, opcional).
Entrada de especificación de lenguaje en PDF [6], para los casos en que la propia
codificación no conduzca por si misma a un lenguaje determinado.
FD (tipo diccionario, opcional).
Diccionario que identifica un conjunto de clases de glifos en una fuente CIDFont y
altera para éstas los valores que se especifican en su font descriptor. Es decir, contiene
excepciones a los valores por defecto del descriptor de fuente.
CIDSet (tipo flujo, opcional).
Flujo que presenta los CIDs que se emplean en la fuente CIDFont. En caso de que esta
entrada se encuentre presente, dicha fuente contiene sólo un subconjunto de los glifos
dentro de la colección de caracteres que engloba su entrada CIDSystemInfo. Si no
se tiene esta entrada, sólo la etiqueta de las fuentes subset puede indicarnos que se
trata de una fuente subset.
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
5.9.
82
Programas fuente incrustados
Los programas fuente incrustados se presentan en PDF en forma de objetos de flujo, también
llamados font files y son susceptibles a copyright. Es importante remarcar la importancia de
este hecho, dado que este proyecto se basa en la incrustación de fuentes de las que disponemos
externamente. Sin embargo, no es competencia de este software el comprobar las restricciones
que tienen impuestas las fuentes que se emplean, siendo este asunto responsabilidad de quien
adquiera dichas fuentes y decida utilizarlas con éste.
Generalmente, un programa fuente no presenta restricciones de incrustación, siempre que
ésta se realice con la finalidad de visualización e impresión del documento y en ningún
caso para crear o modificar texto. Estas dos últimas operaciones requerirían en la mayoría
de las ocasiones, de copias con licencia de estos programas. Así, en ausencia de información
contraria, las aplicaciones de PDF deben asumir que los programas fuente que se encuentren
incrustados, sólo se pueden emplear para los dos objetivos mencionados de visualización e
impresión.
Dado que este proyecto lo que pretende es la mejora de la visualización e incrustación de los
archivos PDF, en la mayoría de los casos las licencias de fuentes son permisivas al respecto.
Sin embargo, se remarca al usuario de esta aplicación, que debe atenerse a las condiciones
que les impongan las fuentes de que disponga o adquiera para incrustar, siendo el único
responsable del mal uso de este software.
Se procede a continuación a presentar la estructura de los programas fuente incrustados.
5.9.1.
Estructura de los programas fuente incrustados
Un descriptor de fichero que introduzca un programa fuente incrustado contempla entre sus
entradas una de las siguientes: FontFile, FontFile2 o FontFile3. La presencia de una de
estas entradas excluye las otras y se diferencian por el tipo de fuente al que refieren:
FontFile: Esta entrada indica que el stream de fuente contiene un programa fuente
Type 1 en forma no compacta o CFF que se describe en Adobe Type 1 Font Format.
Así, la encontraremos para diccionarios fuente con subtipo Type1 o MMType1 que
refieran a su descriptor.
FontFile2: Esta segunda opción señala la presencia de un programa fuente True Type
y se aparecerá en los descriptores de fuentes True Type y derivados de True Type, como
los CIDFontType2.
FontFile3: El diccionario de flujo de fuente en este caso, presentará distintas opciones
presentadas según una entrada Subtype:
• Type1C: se puede presentar para fuentes Type1 o MMType1 pero en el formato
de la fuente Type1 será compacta, es decir CCF15 .
15 Véase
Adobe Technical Note #5176, The Compact Font Format Specification [2].
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
83
• CIDFontType0C: presente en los descriptores para fuentes CIDFontType0, es
decir, en fuentes basadas en Type 1 que como en el caso anterior, se encuentra
en formato CFF.
• OpenType: El formato OpenType16 es una variación de las fuentes TrueType
que permite el uso de programas fuente que se ajusten al formato CFF. Así,
es posible la aparición de esta entrada en descriptores de fuente para los tipos
siguientes de diccionarios fuente:
◦ TrueType o CIDFontType2
◦ CIDFontType0
◦ Type 1
Se deduce de este análisis, que existen varias posibilidades para incrustar un mismo tipo de
fuente, variando sólo el formato de ésta de una opción a otra. De todas las propiedades que
de esta flexibilidad se derivan, se obtendrán herramientas muy útiles para llevar a cabo este
proyecto, como se verá en su desarrollo.
Además, el diccionario de flujo del programa fuente incrustado, incluye según el tipo de
dicha fuente otras entradas como son Filter, Length, Lenght1, Lenght2 y Lenght3
relacionadas con el filtro que se aplica al incrustar el fichero fuente o las longitudes del
mismo. No se detallan más en profundidad por no considerarse de especial relevancia para
la comprensión de razonamientos próximos.
Sin embargo, es necesario realizar una matización al respecto de los programas fuente para
True Type. En la selección de glifos para las fuentes TrueType interviene aspectos dependientes de la implementación consumidora o el sistema operativo en concreto. Es por esto que
para conseguir resultados predecibles en todas las aplicaciones para estas fuentes, se deben
seguir una serie de pautas en la creación del documento PDF original:
El programa fuente debe incrustarse.
Las fuentes no simbólicas deben ajustarse a la codificación MacRomanEncoding o
WinAnsiEncoding como valor de su entrada de codificación en su diccionario de fuente
y no incluir la cadena Differences.
Una fuente que no emplee la codificación MacRomanEncoding o WinAnsiEncoding no
debe especificar entrada Encoding.
Así, si el documento PDF de entrada incluye una fuente TrueType que cumple con la primera
de estas premisas, nuestro software ignoraría dicha fuente, dado que ya se encuentra incluida
en el documento. Sin embargo, si la fuente True Type no se encuentra incrustada y no se
cumplen las últimas dos pautas, la aplicación no se responsabiliza de la predictibilidad de
los resultados dado que el PDF original es un documento mal formado.
En la PDF Reference 1.7 [7], nota primera de la página 430, se advierte sobre este problema:
16 Véase
OpenType Font Specification [46].
CAPÍTULO 5. ANTECEDENTES III: GESTIÓN DE FUENTES PDF
84
“Some popular TrueType font programs contain incorrect encoding information. Implementations of TrueType font interpreters have evolved heuristics
for dealing with such problems; those heuristics are not described here. For
maximum portability, only well-formed TrueType font programs should
be used in PDF files. Therefore, a TrueType font program in a PDF file may
need to be modified to conform to the guidelines described above17 ”
De esta forma, para superar las dificultades, es importante tener muy en cuenta la composición de los programas fuente True Type que se emplean en la creación de documentos
PDF.
5.10.
Resumen
Con este capítulo se ha pretendido proporcionar los conocimientos básicos para comprender
la gestión de fuentes en PDF. Debido a la importancia de este asunto, cuyos fundamentos
se emplean con profusión en el desarrollo de este proyecto, se le ha dedicado una especial
extensión, haciendo hincapié en aquellas cuestiones en que se fundamenta la incrustación de
fuentes.
17 Estas
pautas o guidelines se corresponden con las descritas arriba.