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 < % Subdiccionario de recursos fuente >> 23 0 obj % Objeto o diccionario fuente > 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 < > % 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 > 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 > 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 > 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 > endobj 9 0 obj % Diccionario de codificación > endobj 10 0 obj > endobj 11 0 obj % Stream de definición del glifo cuadrado < > 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 < > 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 < >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 < /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 endcodespacerange 100 begincidrange 231 631 633 696 741 749 ...Rangos adicionales... 8518 8581 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 > 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.