Parto de la base de que mi participación principal en la cadena productiva de un libro ha sido hasta ahora al comienzo, como autor y coautor. Tengo, no obstante, experiencia marginal con la autoedición (quark xpress y ventura), con lo que al menos hay base desde la que hablar. Ventura Publisher me resultó particularmente incómodo, sobre todo por el salto mental que tenía que hacer desde mi hermoso y caótico mundo LaTeX :).
Querría describir un problema que he descubierto en Twitter charlando con @minotaurodigita, @bydiox y @gozque entre otros, que luego hemos dialogado en el post acerca de Libranda, y que creo que necesita reflexión: en este momento, las editoriales trabajan con una cadena de producción inapropiada para los ebooks.
Los libros de papel, salvo la exigua minoría que se prepara en LaTeX, LyX o incluso TeX a pelo como los onvres, se maquetan con programas de autoedición. Lo mismo que las revistas del quiosco, las herramientas mayoritarias en el sector (InDesign, QuarkXpress y antes Ventura Publisher y otros arcanos) son una versión a la enésima potencia de la caja de imprenta de hace un siglo, o de la linotipia de poco después: las herramientas que manejaron mis tíos hasta comienzos de los 80. Si bien la diferencia de capacidades y los resultados productivos son difícilmente comparables, la autoedición deriva su metáfora básica de trabajo de esas herramientas previas. El texto se ajusta a cajas, una por columna, y las cajas en hojas. Es lo suyo no sólo porque en su momento dicha metáfora facilitó sustancialmente la evolución tecnológica en editoriales e imprentas, sino porque responde con eficacia a un problema específico: como ajustar el aspecto de un texto impreso según una serie de criterios que confluyan en un producto de calidad, bien presentado y agradable a la vista.
Por cierto, para quien le interese: hace poco acabamos de liberar una aplicación web libre para producir PDF desde LaTeX o para producir ePub, que hemos llamado LinoTypeX en honor de los viejos impresores. En breve contaré más sobre ella y mi proyecto eMadrid :).
A lo que iba: a los fieles no les contaré nada nuevo si recuerdo la historia de TeX y Donald Knuth: resumiendo, ese Hombre se taró con lo que para él era una calidad insufrible al ver la tipografía que se empleaba en su Magnus Opus, El Arte de la Programación de Ordenadores. Podría haber prendido fuego a la editorial, o rendirse ante lo inevitable, o buscar otra imprenta... pero no, no él. Decidió emplear su año sabático en generar un motor de composición tipográfica que permitiera, por fin, generar lo que el entendía por textos (tipográficamente) hermosos. 9 años después dio por concluido el invento, y al poco vino otro señor llamado Leslie Lamport que tuvo la amabilidad de facilitar las cosas para que los simples humanos usáramos TeX y preparó un conjunto de macros al que llamó LaTeX. Finalmente, llegó otro individuo llamado Matthias Ettrich que como precalentamiento antes de lanzarse a crear KDE puso los primeros ladrillos de mi amado LyX. De LyX ya os he hablado en otras ocasiones a lo largo de estos años.
Quedémonos en LaTeX, que a efectos prácticos es un lenguaje de marcación con el que definir la estructura del texto (artículo, informe, libro, etc.). Aunque se puede afinar realmente con la estética (hasta extremos sorprendentes, dada la bestial biblioteca de paquetes y clases que los voluntarios han acumulado durante 25 años), la actividad principal que se lleva a cabo con LaTeX se centra en indicarle al motor tipográfico cuáles son las partes estructurales de tu texto: El título, el autor, la fecha, el abstract, los títulos de sección, las referencias bibliográficas conectadas a una BBDD bibliográfica BiBTeX, etc. De hecho, el procedimiento en no pocas revistas científicas es proporcionar a los autores una clase completa de documento con todos los elementos admisibles para un artículo, y el autor se limita a usar la clase que le proporcionan para marcar su texto de la manera apropiada. Con todos los artículos revisados por pares y el proofreading final, el número de la revista en cuestión se construye creando un documento maestro que llame a los archivos .tex de los artículos y genere un índice. Cuando se compila, dentro de la caja negra del motor de composición TeX se ponen a currar los gnomos descendientes de los que creó alquímicamente Knuth y devuelven un texto hermoso.
Si creéis que exagero, y no conocéis LaTeX, poned a prueba LinoTypeX: pegad un texto web en este sitio de prueba y tras un ratito (el servidor está un poco al límite) os devolverá un PDF producido desde LaTeX. Es posible que falle, porque tiene los límites de un script previo que hemos empleado como base: html2latex. Y si no os funciona a la primera la conversión a LaTeX, probad a sacar una versión ePub del documento y luego a sacar la versión LaTeX.
Si tenéis prisa por verlo, os podéis descargar el PDF que he generado a partir del post anterior de tinta-e de aquí. Y excusatio non petita, ya adelanto que ni LinoTypeX, ni siquiera Calibre, pueden garantizar un resultado completamente solvente. Que no se diga luego lo que no he dicho.
No hay ningún misterio en el hecho de que LinoTypeX genere LaTeX (y, a partir de él, PDF) o ePub: parte de un archivo estructurado por un lenguaje de marcación (HTML) y devuelve archivos estructurados con otros lenguajes de marcación. Y ojo, lo que no digo es que la solución para generar ebooks en general y epub en particular pasa por LaTeX. Me limito a hacer constar que son lo mismo: archivos de texto definidos por sendos lenguajes de marcación.
Volviendo a nuestro tema inicial, la enorme diferencia es que InDesign, al igual que Word, trabajan con el principio What You See Is What You Get, lo que ves (en pantalla) es lo que obtendrás. En Word eso nunca fue cierto, pero en un programa de autoedición lo es: lo que se ve en esas enormes pantallas que usan los maquetadores es lo que el lector del libro o la revista acabará teniendo en las manos.
Todos los lenguajes de marcación aplicados a documentos se centran (al menos en origen) en el principio WYSIWYM, What You See Is What You Mean, lo que ves es lo que "quieres decir" (en otras palabras, la estructura lógica del documento). A HTML y a ePub se les puede aplicar CSS, y de hecho CSS es una capa para definir una estética definida por encima de los cimientos de la estructura.
A mi entender, el problema es que se está repitiendo una nueva ronda de errores de traducción del p-book al ebook. La primera ronda la hemos vivido de 2006 a 2009: los primeros lectores o ereaders imitan de manera excesivamente literal al libro de papel. El iLiad, por ejemplo, pasaba páginas con una palanca que rememoraba conceptualmente a una página, y permitía anotaciones con un lápiz que producía las notas como si fueran imágenes. No es sólo que no fueran lo cómodos que debían ser, sino algo bastante peor: los primeros ereaders, sin excepción, desaprovechaban lamentablemente lo que eran: ordenadores especializados (appliances, que dicen los gringos), cuyo punto fuerte era su pantalla no retroiluminada. Durante mucho tiempo no se pudo buscar texto usando un ereader, todo lo más se podían marcar 10 páginas del libro o incluso menos, y ni soñar en subrayar y anotar de forma que los textos y los comentarios se pudieran reutilizar con facilidad (para obtener citas para tus artículos subrayando otros textos, algo tan obvio como maravilloso).
Ese obstáculo se ha superado darwinísticamente: el precio no ha sido el único factor (aunque sí el principal) que está dejando fuera de la carrera a los eufemísticamente denominados ereaders básicos.
La nueva ronda de errores de traducción está en el frente del contenido. Las editoriales, las responsables del libro desde poco después de Gutenberg, siguen ancladas a sus "herramientas tradicionales". Mandaría carallo hablar de tradición en el caso de la autoedición, pero cobra pleno sentido si pensamos en las deudas metafóricas con las herramientas previas que mencionaba al principio del post. Por lo tanto, una vez que el texto ha pasado de las manos del autor al editor (si es el caso), y que la revisión de las pruebas de imprenta ha revelado que los fallos han sido eliminados... se sigue mandando el ebook a maquetar.
El error -insisto, a mi modo de ver- reside en que no se visualiza la diferencia entre libro de papel y ebook. Ambos son continentes del texto final para que éste pueda ser leído, pero un ebook, si está en un formato reflowable, definido por un lenguaje de marcación (hoy ePub o .mobi parece que van a ser los formatos sobrevivientes), no es un libro derivado directamente de las fuentes para el papel. Si un PDF es la imagen literal de lo que va a ser un libro en papel, con todo el trabajo de maquetación correspondiente, un ebook es un documento estructurado. Bien estructurado.
Si se piensa bien, no es correcto llamar maquetación al proceso de generación de ePub (o mobi).
- No se pueden definir las fuentes usadas (muchos ereaders ofrecen una única fuente, el nuevo Kindle va a ofrecer 3 fuentes, 3)
- No se pueden definir cajas porque no existen: el texto es un flujo continuo, sin equivalente literal al paginado físico.
- No hay formateado de texto, porque el usuario es el que define el tamaño de fuente y, en algunos casos, el ancho de columna.
De hecho, me mojo y me tiro a la piscina, incluso aunque sea al caldo de persona maggi en que se han convertido las piscinas municipales de Madrid después de cerrar una parte de las mismas por obras en verano: el lector de ebooks en ereader dedicado está concentrado en lo que el autor le cuenta, en el texto, y el contenido no sólo no le puede importar, sino que no le importa. Alba me pasó hace tiempo para que lo posteara en tinta-e su tutorial para crear un porta-portadas para un ereader... porque, en un ereader, los libros no pueden tener más portada que una imagen a pantalla completa.
Este segundo error de traducción del p-book al e-book que estamos viviendo puede tener solución. Vuelvo a insistir, no es cuestión de convertir de forma automática, porque ningún producto existente garantiza que no haya errores. Eso sí, mientras que es inasumible en términos de calidad que un texto de Word vaya a imprenta, la calidad de un ePub producido por calibre suele ser razonable. Pero la labor principal de la producción de un ebook en formato reflowable, tanto epub como mobi, es asegurar que el texto se presenta de forma consistente en todo momento. Creo que se ahorraría trabajo si el fork entre ebook y pbook ocurriera antes de lo que lo están llevando a cabo en este momento.
La mayoría de las editoriales trabaja así en estos momentos:
autor(procesador de textos) --- editor(procesador de textos) --- proofreading(procesador de textos) --- maquetación(autoedición) --- producción de pdf o de epub
y creo que saldría más a cuenta si se trabajara así, al menos para libros con texto corrido, novela, ensayo, monografía, etc:
autor(procesador de textos) --- editor(procesador de textos) --- proofreading(procesador de textos) --- (1)epub ó (2)maquetación(autoedición).
Tengo que insistir: estoy hablando de texto plano y ereaders dedicados, no de contenidos híbridos como Alicia in Wonderland 4 iPad en el que las ilustraciones se mueven y bailan.
Termino: lo mismo que los fabricantes de ereaders han tenido que aprender y darse cuenta que fabricaban ordenadores dedicados y no "libros electrónicos", muchas editoriales tienen que darse cuenta aún de que el ebook es un continente netamente diferente al papel, que necesita de otra cadena de producción. Lo esencial, a mi modo de ver, es que el ebook que vendan sea completamente consistente, sin un sólo fallo en la marcación.
Tengo la intuición de que si se culmina este proceso se facilitará sustancialmente la superación de otros obstáculos que las editoriales están sufriendo en estos días respecto al ebook. Diría que los obstáculos son ante todo herencias e inercias, y también diría que han de superarlos, por el bien propio y por el de la ciudadanía. En lo que a las editoriales respecta, me tengo que permitir un último consejo que nadie me ha pedido: la gran transición se debe centrar en los contenidos, y en el valor añadido que un buen editor le puede aportar a una buena obra para transformarla en éxito. Es posible que me equivoque, pero el ereader significa para el texto la liberación de la estética, la superación del continente y la centralidad definitiva del contenido. Al menos, para quienes realmente nos importa leer.
