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?
