Cómo son los EPUB de maquetación fija que exporta InDesign 10

Hace poco, coincidiendo con la salida al mercado de Adobe InDesign 10 (CC 2014), dábamos la primicia de su principal novedad: la capacidad de exportar EPUB 3 de maquetación fija.

Sin embargo, una mirada algo más minuciosa a esta importante novedad, ¿qué nos aporta?

A primera vista, la fidelidad del resultado es casi perfecta: fuentes incrustadas bien preservadas, maquetación igualmente respetada, páginas separadas, vídeo etc. Esto convierte sin duda a Adobe InDesign CC 2014 como una herramienta óptima para la creación rápida de este tipo de libros electrónicos, sin más pretensiones.

Las opciones de exportación son simples y directas, aunque dejan desiertas algunas opciones importantes que sí se abordan en el caso de EPUB de maquetación fluida:

Cuadro de diálogo de opciones de exportación EPUB 3 
de maquetación fija en InDesign CC 2014


Sin embargo, en caso de que tengamos nociones de HTML y CSS, ¿es posible hacer «bricolage» dentro de un EPUB 3 tal como sale del horno de InDesign CC 2014?

La esencia de un libro de Maquetación Fija es precisamente ésa, que conserve con precisión la posición, tamaño y aspecto de los objetos, es decir, las cajas de texto e imagen. Esto se consigue con bastante eficacia en la exportación desde InDesign, pero con un «peaje» a pagar: un código HTML un tanto inaccesible. He aquí una muestra:

Pequeño fragmento de código HTML correspondiente 
a un trozo de cuadro de texto en InDesign
Por si no has tenido la paciencia suficiente para ponerte a leer con calma el código de la imagen, simplemente mencionar que InDesign coloca cada palabra individualmente en su sitio, usando etiquetas HTML del tipo . Es decir, aunque nuestra página en InDesign conste de un simple e inocente marco de texto, InDesign lo va a convertir en una especie de puzzle donde cada palabra es una pieza, para conseguir el aspecto fidedigno en el libro ePUB 3.

Sinceramente, desconozco el porqué hacerlo así en lugar de posicionar los marcos de texto como un solo objeto contenedor con un texto fluido en su interior. Si bien es cierto que esta forma de generar el código puede ser algo conveniente a la hora de hacer libros que se leen solos en voz alta (con el efecto «Read Aloud»), es fácil ver que en cualquier caso la fracción de etiquetas —de código— excede con mucho a la fracción de contenido de texto. Además, el CSS responsable del posicionamiento está totalmente en línea (incrustado) dentro de los mismos párrafos de texto, cuando en general la praxis recomendada es la de separar el contenido del diseño, o lo que es lo mismo, el HTML semántico de las hojas de estilo CSS.

Quizá un motivo por el cual se genera este código tan intrincado sea para asegurar a la perfección que no haya ningún tipo de diferencias o inexactitudes entre lo que se ve en InDesign y lo que se ve luego en el libro EPUB3, o sea, que la experiencia sea 100% WYSIWYG.

A veces es posible que al exportar todo un contenedor de texto como un solo bloque DIV dentro del HTML de nuestro libro, haya ligeras diferencias en el tamaño de los textos, la partición por sílabas, el encaje de palabras, etc. Nada que no puedan solucionar unos leves retoques en la hoja de estilos CSS común del libro. Quizá lo que Adobe está diciendo con este código es «mira, lo exporta perfecto pero no lo toques ni un milímetro». Ésa es al menos mi impresión. ¿Qué opináis vosotros?




¿Cómo eran los e-books hace 20 años?

El artículo de hoy va sobre arqueología del libro electrónico, y es que acabo de rescatar del archivo y del olvido un documento que encontré por casualidad en 1995, en la época de la conexión a internet con módems telefónicos de 28.8 kbps, y que, con la perspectiva que tenemos hoy en cuanto a la publicación digital se refiere, bien merece un análisis.

El documento arqueológico en cuestión se trata de un libro electrónico en toda regla. Y no de cualquier libro si no de la mismísima Biblia, con Antiguo Testamento incluido. Está en formato Archivo de Ayuda de Windows (HELP, extensión .hlp) y ocupa poco más de 5 MB de tamaño, ya que no contiene imágenes.



El hallazgo ha sido todo un ejercicio de poner a prueba la solidez de la tecnología de documentación digital. ¿Por qué?

Luego de 19 años, era un misterio saber si se podría recuperar la información. Una vez puesto a buen recaudo el fichero (que venía de un CD-ROM donde se grabó a su vez desde un diskette de 3.5″), habida cuenta que ya cuento no por años si no por meses el tiempo que me queda de disponer de computadoras con unidad óptica, había que ver si se podía abrir.

En primer lugar lógicamente abrí un ordenador con Windows 7 instalado. Al intentar abrir el documento, Windows me informa que es un formato de Ayuda antiguo y que no se puede abrir por defecto. Sin embargo, en lugar de dejarme tirado en la cuneta, el hipervínculo de «Resolución de Problemas» que tradicionalmente lleva a ninguna parte en Windows, ésta vez me condujo a una página dentro del website de Microsoft donde pude descargar una utilidad compatible para la lectura de archivos Help de Windows viejos.

Una vez descargada dicha utilidad, pude efectivamente abrir la Biblia. 

Obviamente es un formato austero, pero quizá nos sorprenda que, ni en tecnología ni prestaciones, está tan lejos de los e-books en formato EPUB que diariamente millones de personas leen en sus e-readers y tablets, a saber:

  • Es un formato autocontenido (no una carpeta con archivos dispersos)
  • Dispone de tabla de contenidos con hipervínculos que llevan a los diferentes capítulos
  • La página del TOC tiene un detalle: hay una imagen, una especie de logotipo que reza «El Autor» cuya maquetación es «responsive» 😉
  • La aplicación de lectura permite cambiar el tamaño del texto en reflujo.
  • Así mismo la aplicación de lectura dispone de un índice alfabético y de un potente buscador. 
  • Como el formato subyacente en el Help de Windows es HTML, el texto es accesible y admite formatos básico.

Siendo así, esta pieza de la arqueología e-book no tiene demasiado que envidiar a un libro electrónico de 2014. Donde sí queda muy patente la brecha generacional es en un detalle que en mi opinión no es menor: evidentemente no hay rastro del mundo 2.0: tomar notas, subrayar, compartir párrafos destacados en Facebook o Twitter, Recomendar, etc. Es 1995 todavía vivíamos esencialmente en un mundo desconectado, donde los libros, la comida, las vacaciones, etc. no se compartían casi en tiempo real con no se sabe muy bien quién ni cuántos. 

¿Nos permitía esa falta de distracciones disfrutar más de la lectura, y de todo en general? Dejo la pregunta en el aire…

P.D.: Como curiosidad final y premio al lector que haya llegado hasta aquí, comentar que el epílogo de esta curiosa edición de la Biblia era éste:




Compartir contenidos de publicaciones digitales

Las publicaciones periódicas digitales al uso (Diarios y Revistas para Tablets básicamente) se abren paso a duras penas en un mercado todavía demasiado reticente a invertir su dinero en la compra de este tipo de productos.

En parte el motivo de esta dificultad estriba en la presencia de un viejo (aunque renovado) y obstinado competidor: la Web. En lo que a contenidos digitales enriquecidos se refiere, en experiencia de usuario, pocas cosas superan a este formato. En una era donde la información que no circula rapidísimamente es descartada, La web ofrece más inmediatez y percepción de frescura que una publicación digital.

En el caso de los diarios tradicionales, las versiones digitales de la inmensa mayoría de ellos son meras réplicas congeladas de su equivalente en papel (un «PDF» por así decirlo). Mientras que el usuario cada vez más promedio va en busca de la página web del mismo diario en busca del titular de última hora o de participar activamente en la sección de comentarios de cada noticia. 

Además, con la evolución de la tecnología CSS y la aplicación de los diseños adaptables (también conocidos como responsive), es posible presentar la información de una publicación con un aspecto igual de atractivo que una App o publicación en papel. La prueba está en el número aceleradamente creciente de diarios o revistas que están adoptando la filosofía «Web App» con plantillas homogéneas entre sí.

Una ventaja de los contenidos web es que pueden satisfacer una necesidad acuciante del consumidor actual: la avidez por compartir lo visto y leído con sus amistades en las Redes Sociales (Facebook, Twitter, etc.) Éste era hasta ahora un talón de Aquiles de las publicaciones digitales al uso, que se presentaban como una especie de «caja negra» donde los contenidos no salían de ella. Si un lector disfrutaba de un artículo de una de estas revistas, ya sea por su contenido o por la experiencia de usuario, no hallaba el modo de compartir su hallazgo con su red de amistades, cosa muy fácil de hacer con —por ejemplo— un blog, ya que la inmensa mayoría ya vienen equipados con sencillos botones de compartir de Facebook, Twitter, e-mail, etc.

Lograr una solución viable e interesante para todas las partes no es sencillo, ni técnica ni económicamente. A menudo los contenidos de dichas publicaciones se descargan en la memoria interna del tablet y hay que «extraerlos» de ahí de algún modo para poderlos compartir.

A partir de aquí, los editores buscan soluciones creativas. Un ejemplo podría ser el del magazine mensual gratuito UNBREAK, donde lo que se hace es capturar una región o una página entera en forma de imagen que se puede luego compartir fácilmente en Twitter o Facebook.

Aspecto del interface de compartir regiones de un artículo como
 imágenes de la revista UNBREAK


Otra opción es la que ofrece por ejemplo la solución de publicación de Adobe, llamada Adobe Digital Publishing, donde es posible replicar los artículos que el editor desee en formato HTML5 y albergalos en una URL accesible de modo que cualquier usuario puede acceder potencialmente a ellos. En este caso lo que se comparte no es una imagen estática si no una copia exacta (o casi) del mismo artículo que está leyendo el usuario que adquirió la revista. Esta técnica podría originar un posible agravio comparativo: ¿Para qué gastar dinero en adquirir una revista digital cuando cualquiera puede entrar a su equivalente via web? Lo cierto es que esta solución es mas bien un método algo desesperado para que el editor elija qué artículos quiere dejar «en abierto» a modo de reclamo vía web y URL. Así, los usuarios que accedan por esta via libre podrán comprobar si merece la pena suscribirse o no a dicha revista, algo que pueden hacer desde esa misma página. 

Además, a partir de un cierto número de artículos visualizados «gratis», aparece una página a modo de Paywall que invita al lector a suscribirse a través de su iPad o al menos a comprar números sueltos de la revista. 

Una revista realizada con Adobe Digital Publishing permite compartir los artículos 
en Twitter, Facebook o Pinterest, así como por e-mail.

Si estos métodos para compartir contenidos y competir así con una WWW ya abierta y en constante actualización fallaran, tengo mis serias dudas sobre la viabilidad a medio plazo de este modelo de negocio. Es posible que el futuro cercano vea una lenta (o rápida) agonía del modelo «app» y vayamos a parar a una web evolucionada, con diseños atractivos, todo tipo de interactividad y multimedia, y a pantalla completa. Pero web en el fondo, con la misma esencia de hace 20 años…

Aspecto de un artículo replicado vía Web a partir de una
 publicación realizada con Adobe DPS




Curso: Producción editorial con InDesign y XML


Como siempre, cada trimestre toca «reinventar» la oferta de cursos de Edición Digital disponibles. Cada trimestre, además de hacer nuevas ediciones de los cursos con mayor aceptación (actualmente serían los de Digital Publishing, iBooks Author y Kindle) procuro sacar siempre algo nuevo del baúl y ofrecerlo de manera atractiva a la comunidad de diseñadores / editores de formatos digitales.


En esta línea, os propongo un proyecto ilusionante: un curso online que querido llamar «La Esencia de la Edición Digital». Bajo este pretencioso título, mi intención es mostrar en tres sesiones de una hora de duración lo que, en mi opinión, es la esencia que subyace en todo proceso editorial, ya sea con fines de impresión en papel o en píxels.




La idea es hacer un recorrido trepidante con constantes idas y venidas de formatos. Partiendo de información ‘en estado puro’ (o sea, una base de datos), transformaremos esos datos sin forma aparente en archivos PDF listos para ser llevados a la imprenta, en libros electrónicos en formato EPUB listos para ser vendidos en una tienda digital, o en archivos permanentes en formato XML que podrán ser guardados para, en un futuro cercano o remoto ser reciclados en esos mismos documentos, o en lo que venga.


Así, veremos como, usando como pieda angular la herramienta por excelencia de edición, Adobe InDesign CS5.5, se podrán maquetar documentos multiformato partiendo de unos datos XML. O bien, el camino inverso, como partiendo de un libro que en su día se maquetó a partir de, por ejemplo, un Word… se puede sacar un XML que a su vez alimente a una página web diseñada en CSS con Dreamweaver, o… ¿por qué no? alimentar a una base de datos, ¡haciendo el camino totalmente inverso!




Así o cualquier otra ruta que se nos ocurra, siguiendo un instinto que nos llevará a la máxima productividad posible en la edición y divirtiéndonos a la vez descubriendo varios y provechosos caminos de reciclaje de contenidos digitales. 

Temario:

0. En qué consiste el XML

1. Etiquetado de contenidos con InDesign

2. Exportar e Importar una estructura XML

3. Automatización de procesos a partir de hojas de

cálculo y bases de datos con XML

4. Validación de DTDs

5. Los estándares DocBook y Journal NLM


6. Ejemplo completo de flujo de trabajo basado en InDesign y XML


Este curso es una apuesta que creo que os puede gustar mucho si realmente vuestra vida profesional gira en torno a la edición en digital. ¡Así que os tengo que avisar que sólo es apto para entusiastas que no se conformen con medias tintas!


Los requisitos para cursar este taller online es tener nociones básicas-intermedias de Adobe InDesign, haber usado alguna vez Dreamweaver y tener algunas nociones del formato EPUB o PDF.

Fechas próximo curso ONLINE:  A partir del 6 de de Julio de 2016


¿Cuánto?

El precio del curso es de 79€. 

¿Cómo?

Regístrate gratuitamente en nuestro Campus Online para acceder al listado de cursos, entre los que se encuentra este (link directo). Desde allí te podrás automatricular abonando el importe del curso instantáneamente usando tu tarjeta de crédito o Paypal.

También puedes ponerte en contacto con nosotros a través del correo electrónico: formacion@publicarendigital.com o rellenando el siguiente formulario de contacto:

Curso práctico de diseño web con Adobe Muse

Las profesiones relacionadas con la publicación de contenidos digitales evolucionan muy rápidamente y por ende hay un riesgo real de quedarse ‘fuera de juego’ en poco tiempo si uno no está atento a estos cambios. Un ejemplo de ello es la profesión de Diseñador de páginas web. ¿Os acordáis de la época en que había que planear un proyecto de Sitio Web desde cero, con páginas en blanco desde Dreamweaver con las típicas secciones de productor-servicios-quiénes somos-contactar? 


Pues bien, ahora la cosa ha cambiado. El mundo de la web se ha vuelto más ligero, volátil, y esos proyectos monstruosos han perdido peso versus el diseño personalizado de microsites, landing pages, etc. Por lo tanto, hay que optimizar los recursos al máximo para optimizar a la vez nuestros presupuestos y no perder el tren.

Es por eso que ahora desde Publicar En Digital hemos añadido a nuestra oferta formativa un nuevo curso: Diseño de Sitios Web atractivos con Adobe Muse.


En este curso, veremos cómo crear fácilmente un sitio web de manera 100% visual, y posteriormente editar cada una de sus páginas, completándolas con toda clase de «widgets» como menús desplegables multinivel, por supuesto sin programar absolutamente nada y con opciones atrayentes para el diseñador gráfico como la inclusión de Fuentes Web para poder hacer diseños realmente atractivos. ¡Lo de hacer páginas HTML que se no sabemos si se verán en una mediocre Times New Roman ya ha pasado a la historia!

Detalle del diseñador visual de Sitios web con páginas conectadas de Adobe MUSE.


Los puntos que cubriremos en este taller presencial son:

  • Diseño VISUAL de la Estructura del sitio 
  • Páginas maestras (como si fuera InDesign!)
  • Añadir Links entre páginas.
  • NUEVO: Diseño web responsive con estilos adaptables
  • Añadir imágenes.
  • Inserción de Widgets de menús, paneles, presentación de diapositivas.
  • Creación de estilos de texto con fuentes Web.
  • Insertar html externo.
  • Insertar mapas de Google, videos en streaming, etc.
  • Creación de sitios web adaptados a Móvil y Tablets, visualmente.
  • Publicar tu sitio.

¿Cuándo? 

Opción online: Del 22/6/2016 al 07/07/2016


El formato online consiste en una parte de autoaprendizaje con los materiales de nuestro Campus Virtual, asistidos por una serie de tutorías en directo mediante un aula virtual, a razón de dos clases de 1 hora por semana.

¿Cuánto? 69€

Puedes obtener más detalles, así como solicitar tu plaza, puedes rellenar el formulario adjunto o bien solicitarlo por teléfono al 93 323 94 35 o bien por e-mail a formacion@publicarendigital.com

Tamaños relativos en CSS: la unidad «em»

 A la hora de exportar un documento en formato EPUB desde Adobe InDesign, frecuentemente lo que más desconcierta al diseñador neófito en estos temas son los cambios en las unidades de medida.


En concreto, InDesign suele traducir todos los tamaños y distancias en unidades relativas. Concretamente, en «em», versus pixels o puntos.


La unidad em es una de las unidades relativas que se emplea en CSS junto con el %. Un em equivale a la anchura de la caja de la letra M mayúscula. De este modo, tanto en una página web HTML como en un eBook en formato EPUB dentro de un lector, al aumentar el tamaño del texto, también aumentan todas aquellas dimensiones especificadas en esta unidad relativa, proporcionalmente (aunque a veces esto varía según el modelo de e-Reader).
Bien, siguiendo con el ejemplo inicial, si exportamos en formato EPUB un documento sencillo de InDesign con sus correspondientes estilos de párrafo, encontramos luego que estos estilos se han traducido internamente al formato CSS:

=

Aquí se puede ver como los tamaños de texto, que en InDesign estaban definidos en pixels (o podrían haberlo estado en milímetros), se han traducido a em. En concreto, el estilo «normal» tiene un tamaño de 1.17em mientras que «títulos» tiene un tamaño de 2.5em.


Éstos son tamaños relativos pero ¿respecto a qué? Es decir, si todos los tamaños de todos los estilos de texto se han especificado en unidades relativas… ¿dónde está el tamaño de referencia?


En general, en diseño web, se toma como referencia el tamaño del texto raíz. Es decir, el tamaño del texto de la etiqueta body . Si en una página HTML, o mejor dicho, si en la hoja de estilos CSS de una página HTML especificamos un parámetro font-size para el body en unidades absolutas, algo así como:


body {
  font-size:12px;
}


este tamaño es el de referencia. Por lo tanto, un estilo de párrafo que especifique un tamaño del texto de 2.5em:


p.titulo {
  font-size:2.5em;
}


se traduce en un texto de tamaño de 30px.


Lo que sucede es que Adobe InDesign tiene la peculiaridad de exportar un HTML y CSS dentro del archivo EPUB resultante con ciertas características. Entre ellas, no se define CSS alguno para la etiqueta body, y se hace un uso extensivo de los estilos de clase aplicados básicamente a elementos DIV o P (párrafos), en lugar de recurrir a más variedad de etiquetas HTML (como por ejemplo, las H1, H2, …, CITE, HEADER, FOOTER, etc.)


Entonces, si no hay un tamaño base para el BODY en el CSS, y el resto de tamaños de todos los estilos están en unidades relativas… ¿Cuál es el tamaño de referencia?


Cuando exportamos un EPUB desde InDesign, aunque seleccionemos la opción de no exportar las modificaciones locales, es muy probable que incluya el estilo de párrafo «Párrafo Básico» (que no podemos eliminar en el panel de Estilos de Párrafo). Así que este estilo aparecerá también en el CSS del EPUB resultante, y es el que tiene el tamaño de texto font-size: 1em.


Esto la verdad no es un gran consuelo. Sobre todo si en todo nuestro libro no hay absolutamente nada marcado como «Párrafo Básico».


Lo que hay que conocer en este punto es cómo funciona el tamaño relativo expresado en unidades de em. Esta unidad es relativa al contexto en la cual está definida en el CSS. Es decir: si por ejemplo tenemos en nuestro HTML un contenedor DIV llamado «main», en el que se ha definido mediante CSS un font-size absoluto de 12px, ése será el tamaño «1em» de referencia para todo lo que haya dentro de ese contenedor. Así, si dentro de ese contenedor hay una serie de párrafos con un estilo de clase «destacado» que defina un tamaño de, por ejemplo, 1.17em:


#main p.destacado {
  font-size:1.33em;
}


es lo mismo que decir que el tamaño del texto de esos párrafos será de unos 12 x 1.33 = 16px, independientemente del tamaño de texto que tenga el «body» (si es que está definido).


Si ese mismo estilo de párrafo (de clase en CSS) se definiera de manera autónoma a su contexto, es decir:


p.destacado {
  font-size:1.33em;
}


el tamaño del texto de esos párrafos sería variable, dependiendo de dónde estuvieran colocados. Si hubiera un párrafo en estilo «destacado» dentro de un contenedor distinto que tuviera definido por CSS un font-size absoluto de 9px, ese texto de ese párrafo pasaría a tener un tamaño de 9 x 1.33 = 12px.


Más aún: si definidos otras medidas más allá del tamaño del texto, como podrían ser los espaciados (márgenes en CSS) de los párrafos, en unidades relativas de em, hemos de tener en cuenta de que estos espacios no son acumulables.


Imaginemos el caso de un EPUB (o una página web) que tiene definido un font-size de referencia en el BODY de 10px, es decir:


body {
  font-size:10px;
}


Luego, tenemos dos contenedores (pueden ser dos DIVs, o dos párrafos) con estilos distintos. En HTML podría ser algo así:

mientras que el CSS podría ser algo como


body {
 font-size:10px;
}
p.subcapitulo {
 font-size: 2em;
 margin-bottom: 1em;
}
p.normal {
 font-size:1.2em;
 margin-top:2em;
}


¿Cuál será la distancia real (en px) entre el párrafo «subcapitulo» y el normal a continuación?


La lógica nos podría llevar a pensar que sería la suma del espacio posterior (margin-bottom) del primer párrafo y el espacio anterior (margin-top) del párrafo siguiente en estilo normal. Es decir:


Espacio posterior del párrafo subcapítulo = 1em
Tamaño de 1em en el contexto del párrafo subcapítulo = 2em = 20px
+
Espacio anterior del párrafo normal = 2em;
Tamaño de 2em en el contexto del párrafo normal = 2 x 1.2em = 2.4em x 10px = 24px


o sea, 20 + 24 = 44 px de espaciado entre ambos.


Sin embargo, esto no es así. Cuando medimos el resultado con la ayuda de unos bordes de CSS y la aplicación Free Ruler (para Mac OS) en Sigil (o en ADE, o cualquiera similar), medimos 24 pixels:



La distancia que separará ambos párrafos será la más grande de entre el margin-top de uno y el margin-bottom del otro.


En CSS3 se ha añadido una medida relativa que siempre hace referencia a la raíz del documento (al «body») y esa unidad es el rem (a diferencia del em). Esta característica de momento no está presente en la mayoría de dispositivos lectores de EPUB, y se emplea más en diseño CSS para la web.


Si estás interesado en conocer más sobre este tema, o te gustaría aprender más a fondo los entresijos del HTML y el CSS relacionado con la maquetación de libros electrónicos en formato EPUB, te recomendamos el curso que impartimos «Edición de eBooks en formato Kindle y EPUB», que puedes consultar en nuestra pestaña de Formación.





Mini cápsula introductoria al HTML y CSS

Hoy en día para dedicarse al diseño, maquetación y publicación digitales es muy recomendable poseer un buen fondo de conocimientos en HTML y CSS, que son la base del diseño web y la estructuración de contenidos digitales en general.


Si por ejemplo eres un diseñador neófito en estas lides y antes de meterte a fondo en un curso de diseño web HTML+CSS quieres introducirte en el tema y saber de qué va todo esto, quizá sea una buena idea que veas esta mini cápsula introductoria en vídeo que hemos grabado desde @publicardigital para que entiendas unas cuantas nociones básicas que además puedas poner en práctica por tí mismo:




Se trata de analizar el HTML y CSS de una página de prueba empleando algunas extensiones del navegador Firefox como WebDeveloper o Firebug



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.