Incrustación de fuentes en EPUB y validación

Una de las cuitas recurrentes del sufrido maquetador de libros electrónicos en formato EPUB y que —con buen criterio— emplea Adobe InDesign para ello, es el tema de la incrustación de fuentes desde este software.


Con independencia de que la editora o distribuida de nuestros EPUBs recomiende o tenga como política no permitir libros con fuentes incrustadas (para que cada lector emplee la que prefiera dentro de la gama que le ofrece el e-Reader), desde la versión CS5.5 de Adobe InDesign la opcion de incrustar fuentes se convirtió en sistemática, es decir, si se elige incrustar fuentes en un EPUB, se incrustan todas. 



En versiones anteriores a éstas, solamente se incrustaban aquellas que fueran «incrustables», o sea las que tuvieran licencia para ser distribuidas. Para que este cambio de forma de trabajar fuera consistente, Adobe optó por pasar por la tradicional ofuscación (encriptación) de fuentes que emplea para el PDF, por lo que aunque EPUB sea de libre distribución, la extracción y aprovechamiento de sus fuentes tipográficas era inviable a priori, puesto que los archivos estaban ofuscados e inservibles.

Sin embargo, este tipo de encriptación provocaba errores de validación en la herramienta estándar EPUBCHECK, que utilizan la mayoría de editoras y distribuidoras. Así, un libro EPUB perfectamente confeccionado con InDesign, al exportar con incrustar fuentes, inevitablemente pasaba a no ser técnicamente válido, aunque se viera perfectamente en la gran mayoría de tablets y e-readers.



¿Qué hacer entonces? La solución fácil e inmediata era volver a los orígenes y no incrustar fuentes, o sea, renunciar a usar nuestras fuentes en los libros.

Sin embargo, en la mayoría de casos es un proceso sencillo reparar este inconveniente. Se trata en esencia de cambiar las fuentes ofuscadas por una copia de las fuentes originales, siempre y cuando seamos conscientes de que estamos autorizados a ello.

El procedimiento es sencillo:

1) Al expandir un EPUB en sus partes componentes (extrayéndolo con una utilidad UnZip) localizamos la carpeta «fonts» dentro de la carpeta «OEBPS». Allí podremos ver que está el listado de fuentes que emplea el EPUB, pero cuyo tamaño de archivo es sospechosamente bajo.




2) Reemplazar estos archivos (.ttf, .ttc, .otf) con sus respectivos sin encriptar, que podemos sacar haciendo una copia desde la carpeta de Fuentes del Sistema. Aquí hay que tener cuidado, a veces no coincide exactamente el nombre del documento que incrustó InDesign y la fuente original. También es posible que InDesign haya fragmentado el archivo original del paquete de fuentes en documento individuales más pequeños para cada variante (Negrita, Itálica, etc.)

Si al final el listado de archivos de fuentes incrustadas a mano es distinto al original que portaba el EPUB, habrá que hacer también modificaciones en la hoja de estilos CSS del mismo así como en el documento XML «content.opf», como se ve en las figuras:

Hoja de estilos CSS, mostrando un fragmento donde se referencia a la fuente incrustada


Fragmento de un documento content.opf donde se muestran las líneas responsables de referenciar a las fuentes incrustadas

3) Finalmente, en la carpeta META-INF, hay que eliminar el documento llamado «encryption.xml» que es el responsable de informar sobre el cifrado de las fuentes.

De este modo, un EPUB que no validaba con EPUBCHECK, ahora lo hará y conservará las fuentes que elegimos para su diseño. Esto garantiza la validez técnica del archivo, pero no tiene porqué garantizar que la tienda de destino acepte nuestro libro, si tiene como política que los libros no deben usar fuentes propias.


Páginas web ricas en tipografía

Hasta ahora uno de los hándicaps más habituales que los diseñadores gráficos se encontraban a la hora de publicar contenidos en la web era el entorno pobre en fuentes tipográficas que era la web. Era común plantear un grafismo usando, por ejemplo, Photoshop® afinando al máximo el look & feel para que posteriormente el experto en maquetación HTML nos devolviera a la cruda realidad espetándonos un árido «con esta fuente no puede ser, cámbialo todo a Arial…» o similares.


El motivo de esta barrera gráfica a la hora de presentar unos textos en la web con un aspecto adecuado estriba en que las páginas HTML en un inicio empleaban familias de fuentes tipográficas ubicadas en el ordenador del navegador del cliente, que podía ser cualquier cosa. Así, un párrafo en una página HTML venía marcado con un estilo que incluía dicha familia de fuentes, a saber:


font face=»Arial, Helvetica, sans-serif» …


Este fragmento de código HTML venía a decir que el texto a continuación se intentaba representar en fuente Arial. Si ésta no estaba disponible en el Sistema del cliente, el navegador pasaba a intentarlo con la Helvetica (más típica en Mac) y por último, empleaba el código especial «sans-serif» para utilizar la tipografía de palo seco por defecto de dicho Sistema.


Este método garantizaba una representación más o menos homogénea del texto en HTML, independientemente de la plataforma utilizada para representarlo. Pero aún así el abanico de tipografías disponible era muy escaso, y obligaba a menudo a optar por alguna de estas «soluciones»:

  • Resignarse a emplear una familia tipográfica ajena al grafismo proyectado en un principio
  • Sustituir los textos por imágenes GIF, creadas con un programa de diseño gráfico, con tal de respetar el grafismo
  • Sustituir el texto HTML por texto en formato Flash (SWF)
En el segundo y tercer supuesto, el remedio podía ser peor que la enfermedad: por un lado había que asegurar de colocar un texto alternativo a las imágenes (por aquello de la accesibilidad y de la indexación del contenido correctas) y por otro lado hacía muy difícil la actualización de los contenidos.

Con la evolución del diseño web, y el nuevo paradigma de separación de los contenidos en HTML del grafismo en CSS, se abría una posible puerta a la revolución tipográfica en la web: incrustar la fuente peculiar en el código CSS a costa de subir los archivos de la fuente necesarios al servidor web.

Esta solución presentaba un problema adicional: no era posible dejar un archivo de una fuente tipográfica en un directorio del servidor web potencialmente accesible de manera pública, de tal modo que podríamos incurrir en estar distribuyendo libremente una fuente licenciada, cosa que lógicamente no se debe hacer.

pequeña muestra de algunas de las tipografías que ofrece Google Font Directory


Pues bien, parece ser que la era de la web tipográficamente pobre o repleta de parches de texto-imagen toca a su fin. Existen en la actualidad diversos servicios web que ofrecen utilizar hojas de estilos CSS vinculadas a sus servidores, donde también residen fuentes propietarias de libre uso. Google Labs por ejemplo ofrece el servicio de Google Font Directory.

Este servicio permite al diseñador web añadir vía HTML o Javascript una hoja de estilos situada en los servidores de Google, que a su vez alberga un catálogo tipográfico de libre uso. Un ejemplo de cloud computing aplicado al diseño. Si usamos ya sea el Google Font API junto con sus fuentes, o simplemente para cargar las fuentes de otro proveedor de fuentes web, será posible alcanzar diseños HTML más eficientes, donde no sea necesario sustituir texto por imágenes para alcanzar un grafismo atractivo en nuestras páginas web.


Medidas y tamaños en CSS

Los libros electrónicos en formato EPUB usan, como las páginas web en HTML, estilos CSS. Es esta hoja de estilos CSS la responsable de aplicar un tamaño de letra a los diferentes párrafos, titulares, etc. así como determinar la medida de las imágenes, los márgenes, etc.


Ahora bien, existen multitud de varas de medir en CSS. Hay unidades que son absolutas (como el centímetro, el píxel) y otras que son relativas al tamaño de la pantalla o al tamaño de la tipografía. Si a esto le sumamos que hay multitud de tamaños de pantalla o visor, junto con otra disparidad de resoluciones de los diferentes dispositivos, el barullo con el que se enfrenta el diseñador a la hora de maquetar un libro electrónico o una página web puede llegar a ser considerable.


Para intentar arrojar algo de luz sobre este asunto, he preparado un pequeño experimento sobre medidas en diferentes unidades aplicadas a una hoja de estilos de un eBook. Pero antes, un breve repaso a las principales unidades de medida que se emplean en CSS:

  • Centímetros (cm), pulgadas (in) y  milímetros (mm): se emplean para maquetaciones en papel y quizá también para lectores de tinta electrónica
  • Puntos (pt): es por definición un píxel en una pantalla de resolucón 72 dpi, o sea, 1/72 de una pulgada. Las pantallas tienen una resolución aproximada a esta, pero difieren entre sí.
  • Píxels (px): un punto en una pantalla, sea cual sea su resolución
  • Eme (em): tradicionalmente en tipografía es la anchura de la caja de la letra EME, que es la más ancha de todas (en tipografías de ancho de caja variable). Es una unidad relativa entonces al tamaño de la tipografía, sea cual sea ésta.
  • Porcentaje (%): es una unidad relativa al tamaño del visor del documento. En una página web, es relativa la anchura (o altura) de la ventana del navegador. En un eBook, será relativa la anchura de la pantalla de visualización.
Para este experimento, lo que hice fue modificar la hoja de estilos CSS de un libro electrónico en formato EPUB. Concretamente, varié el margen interior del libro (el «padding») y le puse varios valores en varias medidas, en concreto: 3 em, 20%, 50px, 20 pt y 3 cm. 

A continuación, me puse a medir literalmente sobre la pantalla de mi ordenador y sobre la pantalla de mi lector de eBooks para comprobar sobre el terreno si los cambios que había introducido se correspondían con la realidad. Éste es el resultado de mi experimento:

CASO DE 3 em

Debido a que en la hoja de estilos, el tamaño de la tipografía estaba establecido a 1em, lo que hice fue literalmente colocar «emes» en el margen y contarlas, tanto en la pantalla del ordenador (usando Adobe Digital Editions, ADE) como en la pantalla del lector Cool-er; y variando el tamaño de la tipografía con los controles a tal efecto en ambos dispositivos.

En el caso de la combinación ordenador/ADE al 100% y 200% de tamaño de la tipo:

(tamaño natural)
(primer aumento)


podemos ver como efectivamente el margen mide 3em. En el caso del eReader la cosa cambió:

(tamaño natural)
(primer aumento)



aunque parece que el tamaño del margen se mantiene proporcional (1 cm vs. 1,5 cm medido directamente en pantalla), no es exactamente el tamaño de tres cajas de eme mayúscula.

CASO DE 20%

En el caso de un margen del 20%, es preciso tanto aumentar y disminuir el tamaño de la tipografía como el de la ventana del visor. Claro, esto no es posible para el eReader, ya que el tamaño de la pantalla es el que es y no se puede cambiar físicamente. En el caso del ADE, es el tamaño de la ventana de la apliación, así que es sencillo. 

  • Cool-er: el margen se mantiene idéntico para cualquier aumento de la tipografía. Midiendo la proporción con una regla entre el margen y la anchura de la pantalla, obtengo el cociente 1,8/9 cm = 20%. Perfecto. El porcentaje es la solución óptima para mantener siempre la misma anchura de margen para un libro dentro de un eReader.
  • ADE: Para el tamaño natural de tipografía y un tamaño arbitrario de la ventana, y midiendo en píxels, obtengo el cociente 118/600 (19,7%). Cambio el tamaño de la tipografía así como el tamaño de la ventana y obtengo el cociente 86/432 (19,9%). Perfecto nuevamente. El margen se mantuvo proporcional.
CASO de 50 píxeles

Aquí hay un pequeño problema: no se como medir píxeles en el eReader, ya que las medidas las hago con una regla normal y corriente, que va bien para hacer medidas relativas, pero no contar puntitos. En el caso del ordenador tengo una pequeña utilidad que es una regla virtual, que me deja medir en pulgadas, píxels y centímetros:
(midiento el tamaño de una EME) en píxels
Los resultados fueron los siguientes:

  • Ordenador/ADE: diferentes tamaños de ventana, diferentes aumentos, y siempre estaba ahí el margen de 50 píxels, clavado. Perfecto.
  • Cool-er: el margen se escala de manera proporcional a medida que aumento el tamaño de la tipografía. Esto no es obviamente lo que uno espera para una medida fijada en concreto. Además, las medidas que tomé sobre la pantalla (en cm.) no parecían guardar correlación con los 50 píxeles dados. Por ejemplo, para el tamaño natural, el margen fue de 1 centímetro. Teniendo en cuenta que la resolución de la pantalla del Cool-er es de 170 ppp (píxels por pulgada), un margen de 1 centímetro debería corresponder a un tamaño de 67 píxels, no de 50. Así que, de momento, misterio…

CASO de 20 PUNTOS

En este caso hay que tener en cuenta la resolución exacta del dispositivo. En el caso del Cool-er, como ya se mencionó antes, es de 170 ppp (píxels por pulgada). En el caso de mi MacBook de 13,3″ es de 96 ppp. 

Aquí me encontré con un caso similar al de los 50 px, es decir, midiendo píxeles en la pantalla del ordenador (nuevamente cambiando tamaños de tipo y ventana) me daba siempre 27 píxels. Teniendo en cuenta la resolución de mi pantalla, salen unos 20,3 puntos (el cálculo lo dejo como ejercicio al lector) bastante aproximado a los 20 puntos del estilo.

En el caso del Cool-er, me salen nuevamente medidas proporcionales, que cambian con el tamaño de la tipografía, pero que al intentar hacer el cálculo equivalente con la resolución de 170 pp me salen valores lejanos a los 20 puntos (40, 54, etc.)

CASO de 3 CENTÍMETROS

En un nuevo intento de fijar el margen del libro en un valor fijo y ahora además en una unidad «de papel», propuse a la hoja de estilos CSS un valor del padding de 3 cm. El resultado es el siguiente:

  • Ordenador / ADE: tamaño invariable medido de 113 píxels. A la resolución de pantalla dada, esto da efectivamente 3 cm (nuevamente dejo el cálculo como ejercicio). Perfecto.
  • Cool-er: nuevamente me encuentro con tamaños de margen variables y proporcionales al tamaño de la letra. Para el tamaño natural, mido 1,9 cm, para el primer aumento 3,3 cm, etc. Aquí está la prueba:
Conclusiones

Después de medir medir y medir, podemos sacar algunas conclusiones:

  1. La única manera de mantener un margen del libro fijo en el eReader es usar la unidad porcentaje (%). Casualmente, una opción que en el Adobe Digital Editions dependerá del tamaño de la ventana.
  2. El lector Cool-er (almenos) escala proporcionalmente otras medidas del documento además del tamaño de letra, cuando se pulsa el botón de cambiar ésta y parece que no respeta una medida fija, sea cual sea ésta. Esto concuerda con el comportamiento de las imágenes, que se escalan proporcionalmente aunque en la hoja de estilos tengan un tamaño fijo (cosa que no sucede en el ADE).
  3. Emplear la unidad EME (em) puede ser lo más óptimo ya que se adapta a cambios en el diseño que incluyan el uso de otra tipografía, aunque ésta no sea occidental.
Espero que este post os haya ayudado a entender un poco las unidades de medida en el mundo de la publicación de documentos digitales.