Curso online de CSS avanzado para EPUB

A día de hoy, aplicaciones como Adobe InDesign CC 2014 produce libros electrónicos en formato EPUB (versión 2 o 3) de manera bastante eficiente. Atrás quedaron los tiempo de las versiones CS3, CS4… donde el resultado de la exportación de un documento EPUB requería casi obligatoriamente de editar las hojas de estilo CSS de forma manual para lograr un resultado mínimamente profesional.



Sin embargo, si te dedicas a la edición de e-books en este formato EPUB, es recomendable tener cierto dominio del lenguaje de estilos CSS aplicado a los libros electrónicos, por varios motivos:

  • La interpretación de los estilos CSS varía dependiendo de la plataforma o entorno (e-reader, Android, iBooks, etc.)
  • Algunos ajustes finos en el aspecto del texto o filigranas requieren de una edición detallada de las hojas de estilo CSS
  • Libros más sofisticados pueden requerir del uso de varias hojas de estilo
Es por eso que, si ya sabes cómo maquetar e-books en formato EPUB a un nivel básico, te ofrecemos un taller online donde te enseñaremos algunas técnicas avanzadas de lenguaje CSS para que aprendar a depurar la maquetación de tus libros electrónicos para que tengan un acabado perfecto. En este curso trataremos los siguientes temas:
  1. Controlar la partición de sílabas 
  2. Control de viudas y huérfanas 
  3. Mantener palabras o párrafos unidos 
  4. Ejemplo práctico: poesía en EPUB 
  5. Uso de pseudoclases CSS 
  6. Transformaciones geométricas Webkit 
  7. Capitulares y Versalitas
El curso tiene una duración de un mes, durante el cual podrás acceder a tutoriales, ejercicios y archivos de ejemplo, foros, etc. y que incluye tres sesiones en directo con el profesor.

¿Cuándo?  

a partir del 9 de Julio de 2015

¿Dónde? online, cómodamente desde tu casa u oficina 😉

¿Cómo obtener mi plaza? 

Simplemente date de alta en nuestro Campus Virtual y automatrículate en el curso que desees. O llámanos al +34 606 13 14 84 o por e-mail a formacion@publicarendigital.com





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?




Maquetando poesía en EPUB (2): Partición de estrofas

En el artículo anterior de introducción a esta serie dedicada a la maquetación de poemas en EPUB, se había introducido una técnica para evitar la partición (ni por palabras ni por sílabas) de los versos de una estrofa, mediante la añadidura de una propiedad CSS a tal efecto. De este modo es posible asegurar que el reflujo del texto dentro del e-reader (al cambiar el tamaño del cuerpo del texto) no rompa los versos del poema de ninguna manera, preservando entonces la disposición visual de los mismos y facilitando entonces la lectura e identificación de la métrica del poema.

Sin embargo, la contrapartida es que el texto de dichos versos puede acabar desbordándose por el margen derecho de la pantalla, quedando por lo tanto invisible para la lectura.

En esta segunda parte vamos a abordar tres técnicas adicionales de control de versos y estrofas. De este modo dispondremos de más recursos a la hora de abordar el problema de cómo queremos que se visualicen nuestros poemas en EPUB una vez que éstos refluyan por la pantalla del e-reader (o tableta, o smartphone claro está):

He aquí de nuevo un ejemplo de poema maquetado en Adobe InDesign CC. Se trata de una Rima de Gustavo Adolfo Bécquer, donde al igual que en el ejemplo del artículo de introducción, se ha limpiado el texto original de tal modo que cada estrofa es un solo párrafo y cada verso está separado por saltos de línea forzados.:

En una de las estrofas de esta rima, aparece al final un verso suelto con una sangría diferenciada:

Aquí la persona que en su día transcribió este verso recurrió a acumular caracteres de espacio en blanco para implementar dicha sangría. Lógicamente existen otras formas de hacer esto, tanto en maquetación fija para papel como en maquetación fluida para dispositivos electrónicos. Sin embargo esta forma de sangrar nos sirve como ejemplo para conocer qué sucede con toda esta ristra de espacios en blanco una vez exportamos este documento a EPUB. 

InDesign añade todos esos espacios en blanco en el código, pero lo hace como caracteres básicos no como entidades HTML de espacio de no separación, que sería interpretable por el lector ADE, así que obtenemos este resultado:

donde se puede apreciar claramente que desapareció la sangría. El código HTML generado sería el siguiente (el estilo de párrafo de las estrofas en este caso se llama ‘estrofa’):
el espacio en blanco que se ve antes del verso de «Tal es la inspiración» son dichos espacios en blanco —copiados y pegados desde el código en Dreamweaver— pero que el lector lógicamente ignora, al igual que lo haría un navegador web.

Una forma sencilla de que el e-reader respete literalmente el formato manual de una estrofa, fabricada a golpe de saltos de línea, espacios o tabulaciones, para disponer los versos de una manera peculiar determinada, es establecer una equivalencia entre un estilo de párrafo de InDesign y una etiqueta HTML específica que respete esos formato manual. Una opción podría ser dedicar un estilo de párrafo específico a esas estrofas y, en la definición de dicho estilo en InDesign, asignarle manualmente la etiqueta reservada para texto preformateado en la opción ‘Etiquetas de exportación’:



Al hacerlo, el aspecto visual a base de formatear añadiendo espacios se preserva en el lector. Sin embargo, al igual que cuando forzábamos la no partición de los versos, si aumentamos demasiado el texto, éste se acaba perdiendo por el margen derecho de la pantalla:

El código HTML equivalente que exportaría InDesign para este estilo de párrafo específico sería el siguiente:


donde se emplea la etiqueta «pre» en lugar de la de párrafo «p».

Otro asunto pendiente es la separación de las estrofas en páginas. En este caso, la rima consta de estrofas compuestas por cuatro versos cada una (excepto las que tienen ese ‘verso suelto’ extra, que tienen cinco). En la imagen anterior se puede observar que al final aparece, solitario, el primer verso de la siguiente estrofa. Esto es fruto del reflujo de texto, que va rellenando «pantallas» a medida que vamos cambiando el tamaño del mismo o, en el caso de ADE para ordenadores, también el tamaño de la ventana del software. 

Si no queremos que esto ocurra, podemos optar por varias soluciones:

1) Desde el mismo InDesign, podemos editar el estilo de párrafo de las estrofas, y ahí en Opciones de Separación, activar la opción de «Conservar todas las líneas juntas» de cada párrafo de ese estilo:

Este cambio tiene un doble efecto: además de conseguir que las estrofas no se dividan en la paginación que hace el e-reader al refluir el texto, también hace lo propio en las páginas del documento de InDesign. Al exportar dicho documento a EPUB, InDesign consigue este efecto modificando la propiedad CSS orphans (huérfanas) de este modo:

  orphans:99;

2) Dejando intacto el estilo de párrafo en InDesign, una vez exportado el EPUB podemos editar la hoja de estilos CSS que éste genera, y modificar allí el estilo de las estrofas añadiendo una propiedad adicional: display: inline-block;

con Adobe Dreamweaver es sencillo retocar el código CSS con precisión con la ayuda de la opción de autocompletar dicho código mientras se escribe. Aquí en la última línea de CSS se añade la opción «display: inline-block» de esta manera.


De este modo, utilizando cualquiera de estos dos métodos, al visualizar el poema en el lector tipo ADE, el poema sólo puede leerse en estrofas completas y no partidas, aunque se induzca el reflujo de texto cambiando el tamaño de la ventana o el cuerpo del texto, como se puede apreciar en el siguiente vídeo:

Sin embargo, y ya para finalizar, se puede observar que todavía los versos pueden partirse por sílabas. Si no queremos que se produzca ese efecto, es posible hacerlo, pero tendremos que recurrir a editar levemente el código CSS si queremos que surja efecto tanto en iBooks de iPad como en e-readers tipo ADE (Sony Reader, por ejemplo).

En las opciones del estilo de párrafo en InDesign, si desmarcamos la opción de Separación por sílabas, ésto tendrá efecto en el estilo CSS equivalente al exportar en EPUB de la siguiente forma:

          -epub-hyphens:none;
    -webkit-hyphens:none;

Sin embargo, éstas dos propiedades no funcionan en ADE. Es preciso añadir una propiedad extra específica para este tipo de lectores («adobe-hyphenate»), de tal modo que el fragmento de código CSS resultante modificado quedaría así:


     -epub-hyphens:none;
  -webkit-hyphens:none;
  adobe-hyphenate:none;

De este modo nos aseguramos que ningún verso de las estrofas de ese estilo se partan por sílabas.

Existen otros muchos métodos para manipular los estilos CSS de un archivo EPUB de tal modo que se acomoden a nuestras necesidades de maquetación. En próximas entregas de esta serie de artículos dedicados al género de la poesía iremos desgranando algunos más. 

Por lo pronto, si estás interesado/a en aprender más de estilos CSS aplicados a EPUB, te puedo recomendar mi curso en vídeo «CSS específico para EPUB» para que puedas aprender a tu ritmo y desde casa este interesante mundo:


Maquetando poesía en EPUB (1): Introducción

A raíz de un interesante debate técnico en un foro sobre cómo maquetar poemas en formato electrónico, he decidido dedicar una pequeña serie de artículos a esta materia. Aunque no es una tarea complicada, diseñar libros de narrativa electrónicos en formato EPUB 2 tiene sus intríngulis, más aún si se trata del género lírico, donde las diferentes métricas a respetar han de encajarse en un entorno de texto fluido al antojo del lector (dicho aquí «lector» en el sentido amplio, tanto la persona que lee como el aparato e-reader).

Así pues, me dispongo a desglosar paso a paso algunos aspectos de la maquetación de poemas en este formato, siguiendo un flujo de trabajo basado en Adobe InDesign CC y, por supuesto, en CSS; y enfocado tanto a e-readers de la clase de Adobe Digital Editions como iBooks para iPad/iPhone.

Éste sería el aspecto típico de un poema «en bruto» tal y como puede aparecer tras colocarlo desde un archivo de texto, Word, o copiando y pegando:

Al mostrar los caracteres ocultos podemos observar algo frecuente: cada verso es un párrafo, y la separación entre estrofas (el ejemplo de la imagen es un soneto) se hace así mismo con caracteres de párrafo. 

Aunque ésto no sea del todo incorrecto, el primer paso podría ser dejar cada estrofa en un solo párrafo, de tal modo que pudiéramos controlar el espaciado entre los mismos con el espacio después de párrafo en lugar de añadir párrafos vacíos.

Entonces, hay que realizar una primera limpieza del texto en InDesign, sustituyendo los caracteres de fin de párrafo de cada verso por saltos de línea forzados, y eliminando los que separan las estrofas. Es algo que se puede llevar a cabo fácilmente con la ayuda de Estilos GREP (opcion Buscar/Cambiar de InDesign):


Entonces, hay que realizar una primera limpieza del texto en InDesign, sustituyendo los caracteres de fin de párrafo de cada verso por saltos de línea forzados, y eliminando los que separan las estrofas. Luego, se puede crear y aplicar un estilo de párrafo para cada una de las estrofas, de tal modo que al final tendríamos algo como ésto:


Aquí, en la definición de dicho estilo de párrafo, aunque hayamos especificado en Opciones de Separación y Separación por sílabas que no queremos que las líneas se partan o que las palabras se rompan, al exportar en EPUB estos ajustes no tendrán efecto. He aquí el aspecto de dicho poema una vez que lo visualizamos en Adobe Digital Editions, a tamaño normal del texto:

Sin embargo, al aumentar el tamaño del texto y/o cambiar el tamaño de la ventana de ADE, para provocar el reflujo del texto habitual, obtenemos lo siguiente:

Que no es, claro está, el aspecto que deseamos, ya que han aparecido de todos modos particiones por sílabas que rompen los versos. 

En este punto, hay que realizar un sencillo retoque en los estilos CSS del libro EPUB. Con CSS es posible evitar dicha partición por sílabas de las palabras, pero en este caso queremos ir más allá, evitando que los versos se puedan llegar a partir incluso por palabras. Esto lo podemos conseguir añadiendo una propiedad adicional al estilo de párrafo CSS de las estrofas, en concreto:

white-space: nowrap;

Si usamos editores web como Adobe Dreamweaver, éste nos puede echar una mano a completar el código CSS sin errores de sintaxis:

Al introducir este cambio y volver a reconstruir el archivo EPUB, al visualizarlo con ADE y volver a forzar el reflujo de texto, obtendríamos algo como ésto:

es decir, antes que partirse, los versos quedarían ocultos por el margen derecho de la pantalla. 

Existen propiedades de estilos CSS muy útiles y específicas para el entorno de los libros electrónicos en formato EPUB, que puedes aprender a tu ritmo si lo deseas con el curso en vídeo que te ofrecemos en Publicar en Digital.

En próximas entregas de este artículo continuaremos explorando más detalles de la maquetación de poesía en EPUB, como por ejemplo las sangrías en los versos. ¡Hasta la próxima entrega entonces! 🙂











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:

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.


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.