Esta entrada es la primera de una serie sobre edición digital que publicaremos en este blog. La autoría de los artículos es de Ramiro Santa Ana Anguiano, que oficia de autor invitado.
Por iniciativa de Mariana Eguaras estaremos publicando una serie de entradas dedicadas a la publicación digital, sus características, ventajas y retos, así como su relación con los medios impresos y cómo estas cuestiones afectan directamente a los procesos necesarios para producir cualquier publicación.
Si bien ya tenemos planeadas el contenido de las primeras entradas, cualquier sugerencia sobre temas a tratar será bienvenida. En la medida de lo posible, la redacción no será técnica, sino afín al público en general o a quienes se dedican a la edición.
Sin embargo, también se tiene que tomar en cuenta que algunos tecnicismos ya son imprescindibles para el medio editorial. Así como la jerga de los tipógrafos, impresores o diseñadores es de habitual conocimiento para quienes editamos, del mismo modo el lenguaje del desarrollador web o de software empieza a formar parte de nuestro bagaje cultural.
En esta primera entrada haremos una comparación general entre algunos de los métodos más comunes para producir un libro electrónico estándar en formato EPUB. En su momento se hablará con más detalle sobre la historia del EPUB.
Lo que ahora nos interesa es que, entre los distintos tipos de formatos existentes en el mercado del libro electrónico, el EPUB, desde sus inicios, fue pensado como un tipo de archivo para ebooks que sobresale por su versatilidad, ligereza y seguimiento de estándares web que aseguran una uniformidad en el código, y también un completo control sobre la edición.
Al tener estas características, el formato EPUB es fácilmente convertible a formatos privativos como los empleados por Amazon o Apple, asegurando así un ahorro de recursos y de tiempo al momento de crear una publicación digital.
Esta flexibilidad también ha permitido el desarrollo de diversos programas de cómputo que facilitan la creación de EPUB a cualquier persona. Con un par de clics desde el procesador de textos (Writer o Word) o maquetador (InDesign) instantáneamente tenemos un archivo EPUB a través de una conversión de formatos.
En principio, esto es una gran ventaja para autores independientes o para editoriales que no desean invertir «esfuerzos adicionales» en la producción de un libro electrónico. Sin embargo, existen al menos dos desventajas en estos procesos de publicación:
1. La limpieza del código, el control del diseño y la calidad de la edición en muchas ocasiones son inferiores a lo que es posible obtener a través de otros procesos.
2. Se pierde por completo de vista que lo más importante de la revolución digital dentro del mundo de la edición no es el libro electrónico, sino los procesos que ahora son posibles y que no representan algo «extra» al momento de producir un libro, sea impreso o digital. En su lugar, se trata de un conjunto orgánico de elementos que pueden ayudar tanto en el ámbito técnico de la publicación como en la calidad de la edición.
El libro electrónico es el punto de relieve más característico de la era digital en la edición, pero es solo la punta del iceberg. Para poder ir paulatinamente más a fondo tenemos que empezar a familiarizarnos con lo que está detrás de la producción de un ebook.
Como primera cuestión, existe cierto escepticismo sobre la necesidad de producir una publicación «desde cero». Es decir, se tiende a preferir el uso de conversores que, sin importar la estructura o el contenido de la publicación, automáticamente crean un archivo EPUB.
¿Para qué aprender lenguajes de etiquetado, como HTML o Markdown? ¿Para qué preocuparnos por las hojas de estilo, como CSS o SCSS? ¿Para qué reflexionar sobre el potencial de los lenguajes de programación para generar otras experiencias de lectura o para mejorar el cuidado de la edición, como JavaScript, Python, Ruby o C++?
Porque aunque el objetivo sea un objeto físico o digital, si empezamos a enfocarnos en su proceso de producción, poco a poco nos daremos cuenta de su pertinencia.
Características del ejercicio de comparación
Para mostrar las ventajas y desventajas que presentan los conversores de EPUB, en contraste con el desarrollo de una publicación digital «desde cero», se hará una comparación en la producción de una misma obra, pero con diferentes métodos.
Con la intención de que este ejercicio sea lo más «real» posible, se optó por tomar la edición del Proyecto Gutenberg del Don Quijote. Además, para mantener una uniformidad en la edición se ha partido del mismo texto en formato HTML y se ha usado la misma hoja de estilos CSS.
Algunas dudas respecto a estas decisiones pueden ser:
- ¿Por qué utilizamos la edición del Proyecto Gutenberg si hay mejores ediciones disponibles en línea como puede ser la publicada por el Instituto Cervantes? La edición usada en este ejercicio es de dominio público, así como, a diferencia de la edición de Wikisource, fue sencillo descargar el libro entero en un solo archivo.
- ¿Por qué se parte de un texto previamente formateado, en lugar de vaciar el texto directamente desde los archivos descargados del Proyecto Gutenberg? Al momento de hacer esta comparación se detectaron algunos descuidos en la edición que se decidieron enmendar (aunque sin duda se podrán encontrar más, ya que un cuidado estricto no es la meta de este ejercicio). Por otro lado, el formato del texto casi siempre se presenta como pesadilla para quienes editamos, provocando una mayor inversión de tiempo, recursos y esfuerzo únicamente para limpiarlo, cuestión que trataremos en otra entrada.
- ¿Por qué se emplea la misma hoja de estilo en lugar de recrear el diseño en cada uno de los métodos empleados? El rediseño también involucra una mayor inversión de tiempo, recursos y esfuerzo, además de que el empleo de la misma hoja de estilo deja patente la pertinencia del diseño web para el mundo de la edición y la flexibilidad de poder utilizar esta hoja en los diversos métodos empleados (y obras), tema del que hablaremos en una futura entrada.
- ¿Cuáles son los métodos empleados en este ejercicio? El libro se desarrolló de cuatro maneras distintas: desde InDesign, siendo la forma más común para la mayoría de los editores o diseñadores editoriales; con Jutoh, como ejemplo de software pensado para facilitar la creación de publicaciones digitales; mediante Sigil, por ser uno de los programas más utilizados para la creación de EPUB, y «desde cero», lo cual involucra una intervención directa en los archivos necesarios para el desarrollo de un EPUB.
Comparativa de tiempos de producción: la eficacia del método «desde cero»
Uno de los mayores mitos que existe sobre la pertinencia de la creación de libros EPUB «desde cero» es que este modo de trabajar requiere mayores tiempos de producción. Sin embargo, el desarrollo «desde cero» no quiere decir que todo ha de hacerse de manera manual. Como lo estaremos viendo en otras entradas, mucho del trabajo al momento de desarrollar un EPUB es monótono y fácilmente automatizable a través de la creación de scripts.
Cuando hablamos de la creación de un libro EPUB «desde cero» nos referimos a que no existe un software intermediario que nos ayude a llevar a cabo esta tarea más allá de un editor de texto plano, o de código, y el uso de la línea de comandos.
En un primer momento esto puede sonar como un proceso demasiado complejo y que requiere mucha inversión de tiempo para aprender a llevarlo a cabo. Pero nada está más lejos de la realidad, si bien el desarrollo «desde cero» tiene sus retos, como cualquier otro método, es una habilidad que está al alcance de cualquiera que cuente con una computadora.
Si obviamos el tiempo empleado en darle formato al texto, en la siguiente gráfica podemos observar que en el desarrollo de la misma obra y diseño el método «desde cero» es el más eficaz. Esta diferencia se debe principalmente al tiempo que debe de emplearse en asociar las etiquetas HTML a los estilos creados con anterioridad.
Tanto en InDesign como en Jutoh es necesario asociar cada estilo CSS a estilos de párrafo o de caracteres; la diferencia entre ambos estriba en que en InDesign la asociación es más intuitiva y sencilla que en Jutoh. Por el otro lado, con Sigil o «desde cero» no existe la necesidad de asociación, ya que esta se detecta automáticamente al «enlazar» la hoja de estilos CSS a cada uno de los archivos del contenido del libro; sin embargo, el método «desde cero» presenta la ventaja de que no existe la necesidad de recrear el árbol de directorios o de importar archivos a un programa, como Sigil, para poder crear el archivo EPUB.
Tamaño del EPUB: la incidencia de las imágenes y el código «basura»
En cuanto al tamaño del archivo EPUB, existen al menos dos factores que afectan directamente en su peso, que son 1) las imágenes incrustadas, y 2) la cantidad de código «basura».
La mayoría de los libros EPUB solo presentan una o dos imágenes para la portada o la contraportada, quizá una más si se incluye una fotografía del autor. Aunque se trate de un par de elementos, por lo general estas imágenes tienden a representar los archivos con mayor peso en un EPUB si existen alguna mezcla de estas circunstancias:
- la publicación es relativamente breve,
- las imágenes son más grandes de lo necesario,
- las imágenes no tienen una buena compresión, o
- las imágenes están en un formato poco pertinente.
Ninguna de estas posibilidades son las que afectan al peso de estos archivos EPUB debido a que todas están utilizando la misma imagen de 204 KB.
La diferencia de tamaños tiene una relación directa con la cantidad de código «basura». Cuando hablamos de la existencia de código «basura» queremos decir que, por los mismos resultados, algunos conversores añaden líneas adicionales de código. Sea para dejar patente el software que se utilizó para crear el archivo, o porque el método que asocia los estilos CSS con los estilos de párrafo o de caracteres es la recreación del archivo CSS bajo sus propios lineamientos y convención de nombres.
Esto produce al menos dos desventajas:
- peso adicional e innecesario a la publicación, y
- un cambio de nomenclatura que puede dificultar una ulterior modificación del diseño.
En el caso de los métodos con InDesign o Jutoh, el peso del libro se incrementó por el código «basura» existente; no obstante, la diferencia de peso entre los EPUB hechos con Sigil o «desde cero» es de otra índole que involucra la estructura interna del libro.
Sin extendernos demasiado, a partir de la tercera versión del formato EPUB existen dos archivos para la tabla de contenidos. El formato antiguo es el NCX, mientras que el formato introducido en la tercera revisión del EPUB es el XHTML o HTML.
Por defecto, Sigil solo te genera una tabla de contenido en formato NCX. Esto puede ser un potencial problema si consideramos que algunos de los lectores de libros más recientes solo soportan la visualización de tablas de contenidos en formatos XHTML o HTML.
Debido a esta circunstancia, el EPUB creado «desde cero» contiene tanto una tabla de contenidos en formato NCX (para lectores de libros antiguos) y otra en XHTML, lo cual representa 11 KB de peso adicional para una diferencia de solo 5 KB entre el libro desarrollado con Sigil y el creado con este método.
Errores y advertencias: verificación de los EPUB
Una de las principales ventajas que acarrea el proceso de producir un libro EPUB a través de conversores o software intermediario es que precisamente está pensado para usuarios con poco interés o conocimiento de HTML y CSS. La creación del libro, por lo general es de manera visual e incluso en algunos casos la curva de aprendizaje es relativamente corta.
Sin embargo, además del cuidado editorial y del aspecto estético, un libro electrónico también tiene que tener una estructura interna coherente. Es decir, si la finalidad es desarrollar un EPUB con calidad «profesional», este no debe de contener errores o advertencias frutos de inconsistencias en el lenguaje de etiquetado o de la hoja de estilos, en los metadatos, en los tipos de formatos aceptados o en la compresión de las imágenes.
Para que la búsqueda de inconsistencias sea efectiva y no nos demore mucho tiempo, existen los verificadores de EPUB. La herramienta oficial para verificar estos archivos se llama EpubCheck, la cual tiene una versión en línea como otra disponible para su descarga.
Sin embargo, por lo general un EPUB no solo se verifica mediante EpubCheck, sino con al menos otro software, sea por requerimiento del cliente, sea simplemente para tener otra herramienta de verificación. En el caso de nuestro ejercicio hemos utilizado tanto EpubCheck como una extensión para Firefox denominada BlueGriffon (verificador que varios de nuestros clientes piden utilizar).
Ahora bien, la gráfica que se muestra solo abarca los errores y advertencias detectados por BlueGriffon ya que ninguno de los EPUB presentó inconsistencias al ser verificados con EpubCheck. También cabe resaltar que la cantidad de errores o advertencias es poca debido a que se emplearon los mismos textos en formato XHTML y hojas de estilos, así como los metadatos fueron generados automáticamente por cada uno de los métodos. (La creación «desde cero» utilizó un script hecho por el colectivo Perro Triste y que se ejecuta a través de la línea de comandos).
El error presente en el EPUB hecho con InDesign indica que este programa utilizó un tipo de compresión no válida para la imagen de la portada, mientras que la advertencia es exactamente la misma a las que detecta en los EPUB creados con Jutoh y Sigil: un elemento presente en los metadatos se considera obsoleto.
En realidad, resolver estos errores y advertencias no es nada complicado; no obstante, para un usuario que no está familiarizado con la estructura del EPUB el proceso para enmendarlos puede ser frustrante. Para arreglar estos EPUB es necesario su descompresión de manera externa para ir directamente al archivo que presenta el problema, modificarlo y, por último, volver a comprimir el EPUB.
Costos implícitos en la producción: programas de pago versus software libre
Al momento de producir un EPUB, por lo general el usuario se pregunta si los programas de cómputo necesarios son gratuitos o si tienen algún costo. Afortunadamente, para la producción de un libro electrónico no es necesario pagar por alguna licencia de software.
En la mitad de los cuatro métodos vistos en este ejercicio se empleó software privativo que implica costos para su uso. Tanto InDesign como Jutoh requieren el pago de una licencia, mientras que Sigil es software libre. Para el método «desde cero» se emplearon programas de software libre (Atom, Firefox y el script desarrollado por Perro Triste) y del sistema (la terminal).
Un mito recurrente entre los usuarios que no están familiarizados con el uso de software libre o de código abierto es que su gratuidad es sinónimo de baja calidad. La falsedad de este supuesto —al menos en lo que concierne a la producción de libros EPUB— pudo observarse en este ejercicio: Sigil y el método «desde cero» arrojaron mejores resultados.
No obstante, tampoco puede dejarse de lado que la gran mayoría de las editoriales emplean InDesign para la edición de sus libros impresos, por lo que en determinadas circunstancias lo más conveniente quizá sea irse por esta misma vía para desarrollar libros electrónicos.
Si esta no es tu situación y, al mismo tiempo, deseas mejorar la calidad de tus EPUB, por lo que estás considerando hacer una inversión en software privativo, mejor piénsalo dos veces. Existen otras posibilidades libres y de alta calidad que pueden acomodarse a tus necesidades.
Conclusión: el método «desde cero» gana esta partida
A lo largo de este ejercicio quedó evidenciado que uno de los métodos más eficaces y eficientes para la producción de libros electrónicos estándar es el desarrollo «desde cero». Varios lectores podrán pensar que este modo de producción implica ciertos conocimientos técnicos complejos y una mediana o larga curva de aprendizaje.
Como experiencia, puedo compartirles que a las personas que, por medio de Nieve de Chamoy o Perro Triste, les hemos ayudado a aprender a hacer EPUB, no les ha tomado más de 24 horas de taller el desarrollo de su primer libro electrónico «desde cero». Además, cabe la pena resaltar que la mayoría de estas personas provienen de un contexto de completo desconocimiento de los lenguajes HTML y CSS, así como del uso de la línea de comandos.
Sin embargo, como tampoco se trata de reducir las posibilidades de producción a este único método, en futuras entradas veremos cómo elaborar libros EPUB desde InDesign, Sigil y el desarrollo «desde cero». No trataremos el método desde otros programas (como Jutoh o iBooks Author) porque no lo considero conveniente.
Si se tiene planeado el uso de software exclusivamente para crear libros electrónicos, la recomendación es que sea software libre o de código abierto, para que no involucre costos de producción extra, y cuyos formatos de salida sean estandarizados, como el EPUB (el cual sin problemas puede convertirse a formatos privativos como los usados por Amazon y Apple); por ello, la recomendación bajo estas necesidades es Sigil.
Por otro lado, para no obviar la tendencia editorial de producir libros con InDesign, también se verá la manera más óptima de desarrollar libros EPUB con este programa. Pero antes de esto, el siguiente tema a tratar será sobre un problema rutinario en el quehacer editorial y que, aunque parezca mínimo, representa uno de los cuellos de botella al momento de producir libros, sean impresos o digitales; es decir, hablaremos sobre la manera más adecuada de dar formato a un texto.
Pedazo entrada más completa, muchas gracias por dedicar tantas horas a mostrarnos todos los métodos que hay, me ha sifo de muchísima ayuda todos los programas que mencionas, espero con ansias otra entrada similar.
coincido en todo contigo, formatear el documento y empezar con él desde cero es lo mejor y te da la seguridad de que no hayan complicaciones posteriores, sobre todo cuando ha pasado por varias manos.
Aquí nos dejaste tareas para rato jeje, me pondré a ver todo bien.
Muchas gracias por tus comentarios, Romeo, nos vemos en la próxima entrada, ¡saludos!
Impaciente por las futuras entradas sobre este tema.
Llevo meses dándole vueltas a este asunto.
¡Impaciente de publicarlas! Muchas gracias, Gaztea.
Muy interesante el artículo. Tengo en el mac Jutoh desde el año pasado, me gustó porque puedes plantear el ebook pensando en exportarlo no solo en epub, sino en otros formatos incluyendo para kindle (algo ausente en indesign); lástima sólo este en inglés. Me soprende que se comente que hay código basura tanto en indesign como en jutoh, cuando este último es una aplicación pensada especificamente para hacer ebooks, ¿cual será el motivo?. Habria que plantearse también si ese «método de cero» realmente esta siendo un enfoque editorial (estamos usando un sistema de internet html pasado al mundo editorial). Personalmente quisiera que Adobe no deje de sacar versiones mejoradas para editar ebooks (la última me fue bastante bien para hacer epub3), porque se trata de editar diferentes documentos con una herramienta ágil que te permita reunir toda la información que uses, gestionándote en carpetas los trabajos; y todos sabemos que con un editor de texto no se piensa asi. (Dejo mi comentario en linkedin, donde me enteré del artículo).
Quien mejor puede responder tus dudas, Daniel, es Ramiro.
Sí te confirmo que el trabajo «desde cero» se emplea en algunas editoriales, sobre todo en aquellas que son digitales, como Ganso y Pulpo y Sinerrata.
Ojalá otros profesionales se animen a comentar y contar con qué metodología trabajan.
Gracias por pasarte por aquí y dejar tu comentario.
Mariana! ¿Has probado el lector de ebooks, Marvin 3?
Va muy bien, lo he activado para tenerlo completo y subir los ebooks que guardo en mi dropbox desde la propia app.
Ves muchas características del ebook, personalizas la lectura y guardas las marcas en icloud de manera que te reconoce en otro dispositivo con Marvin ese dato con una función voluntaria (en kindle es automática) de sincronizar.
Lo recomiendo también para quien se haga sus propios epubs, o edite los que tenga para hacerles cambios con Sigil, por ejemplo.
Ni sabía que existía. 😛 Con el lector BQ, la tableta y el móvil me alcanza y sobra. 😀
Yo es que no he pasado por la fase lector de tinta clásico, fui directo al iPad un dia. Tengo pendiente probar un lector clásico.
Acabo de incorporar la foto de una portada a un epub que no la llevaba en la propia aplicación. Esta muy bien. No solo por la app en si, sino por ver el potencial que se le puede sacar a la lectura epub, y un dia a los upb 3.
Hola, Daniel, gracias por tus comentarios. El código basura, como mencioné en el artículo, es ocasionado «sea para dejar patente el software que se utilizó para crear el archivo, o porque el método que asocia los estilos CSS con los estilos de párrafo o de caracteres es la recreación del archivo CSS bajo sus propios lineamientos y convención de nombres». Si te fijas ambos casos no tienen relación directa con la publicación, sino con asuntos de PI para dejar patente el software utilizado durante el desarrollo, y que puede ser una manera eficaz de verificar la autenticidad del software, o la metodología de conversión de los estilos la cual está pensada en evitar conflictos dentro de un ambiente de trabajo que sobresale por la falta de consistencia en los estilos debido a las metodolgías wysiwyg que los procesadores de texto y maquetadores permiten.
Respecto a las desventajas de los procesadores de texto, principalmente Word, no podría estar más de acuerdo contigo; sin embargo, el marco de trabajo planteado por los software de Adobe no es único ni original, y principalmente, no está pensado en primera mano para editores, sino para diseñadores editoriales (InDesign) o diseñadores gráficos (Photoshop, Illustrator). La única excepción es InCopy, pero por lo que he visto, menos del 10% de los editores utilizan esta aplicación y de ahí, sería interesante ver cuántos en realidad hace que su trabajo sea más eficiente.
El enfoque del método desde cero para la creación de EPUB sigue una metodología de trabajo tan afín al enfoque editorial, principalmente en control y cuidado de la edición, que el mayor problema no representa el desarrollo del libro, si hablas de un ebook, o la maquetación de la obra, si hablas de un impreso, sino el formateo del texto. Lo estaremos viendo a largo de varias entradas, pero puedo adelantarte que con el uso de editores de código, la terminal, uso de repositorios git, la aplicación de scripts, la conversión mediante pandoc y el empleo de lenguajes de marcado simple como Markdown, la producción de un ebook, sea ficción o publicación científica (con gestor de referencias bibliográficas, tablas o gráficas) puede realizarse en menos de dos horas: sin errores, sin pérdidas de control editorial, sin la inversión de mayores recursos. Pero bueno, antes de hablar de todo eso, es necesario hablar de uno de los mayores problemas al momento de editar un libro mediante herramientas digitales, sea para impresión o digital, sea con InDesign o desde cero: el formateo del texto. Creo que el siguiente artículo que hablará sobre eso te dejará más claro la pertinencia del método desde cero y cómo esto no quiere decir que abandones tus herramientas actuales.
Por último, sobre la versatilidad de conversión, al ser el EPUB el estándar, es aceptado por todas las plataformas de distribución, o bien, estos proveen de herramientas para la conversión a formatos privativos como Kindlegen de Amazon.
¡Saludos!
¡Múchisimas! grácias a ti, Ramiro; por aportar en internet tan valuosa información. Digo lo mismo que los otros lectores, encantado en leer las siguientes publicaciones.
Con respecto a mi sorpresa cuando referencias a indesign y jutoh en el mismo problema con el código que crean, me ha generado sonrisa socarrona porque me permite pensar que no hay dejadez en Adobe con respecto a este tema y que las herramientas sean de quien sean, son mejorables. Comprendo muy bien! lo de entender el código para hacer ebooks basados en una calidad de edición y que expertos como tu y Mariana y algún profesional más esteis dando a conocer de forma didáctica y espero aprender mejor el tema del formateo (por cierto me gustaria dominar TextSoap) pero si queremos una evolución editorial del ebook, lo debemos basar en herramientas que ya tienen este avance hace años, no es solo pasar texto como si leieras una página web (donde todo esta basado en el modelo inglés) y que los maquetadores sigan sintiendo que usan sus herramientas de siempre; y para mi! Ramiro, no hay una edición mayor de decenas de libros a ebook por culpa de esto; cada 10 dias o asi me pregunto (en bibliotecas, librerias…) ¿porque esto no esta en ebook?. Se editan muchos menos libros de los que se podrian editar y aqui todo maquetador que me lea me dará la razón, algo que no le motiva a ponerse a aprender a hacer ebooks con más perfección o menos. Me gustaria mucho que una reunión del «Grup català d’usuaris d’indesign» (linkedin) pudieras venir y dar un esbozo, porque verias que la gente le encantaria mejorar su experiencia en el tema digital, pero queda todo en plugins, plataformas, trucos, etc… y poca consistencia que haga de esto algo integrado a lo tradicional ya de una vez. ¡Un cordial abrazo!
Bueno, supongo que nos estaremos leyendo y respondiendo en las siguientes entradas, Daniel. Ese pregunta que te haces cada diez días creo que su respuesta va ligada a la metodología empleado durante los procesos editoriales: la mayoría de los editores ven al ebook como una fase más en la producción de un libro. Conforme se vayan publicando más entradas, trataré de mostrar que producir un ebook no es algo adicional, sino connatural a todo esta serie de procesos que más del 90% de las editoriales ya llevan a cabo con software (desde el archivo de procesador de textos hasta el archivo para imprenta). Es curioso, ¿no crees? ¿Por qué si ya se está editando con herramientas digitales para producir libros impresos, no es común que esos mismos libros también se publiquen en digital?
Un saludo desde México, si en algún momento me encuentro en el otro lado del charco, me encantaría a ir a una sesión de ese grupo. ¡Hasta luego!
Yo no puedo estar más de acuerdo con mi querido Daniel, parece que siempre vamos de la mano, pero es el hecho de dedicarnos profesionalmente a la edición digital.
Profesionalmente y si quieres un trabajo de calidad no te queda otra que partir del cero.
Conozco empresas del sector, que si bien maquetan el libro para off a la hora de hacerlo para no usan conversores automáticos.
Si hace sun buen trabajo de maquetación el hacer la conversión con Indd es muy sencillo y de calidad superior.
De todas formas, no hay conversión que luego no tengas que ajustar en xhtml.
Sobre el código basura entiendo lo que quiere decir, pero me parece lógico que programas como sigil o indd «firmen» a la hora de hacer conversiones, ayuda al profesional a saber como se hizo ese libro y el método a emplear para corregirlo si fuera necesario.
Para lo que necesiten.
Un saludo.
No sabia lo que me comenta Ramiro de código que usa la aplicación a modo de firma. Lo que entendia sobre código basura es al uso de etiquetas de forma repetitiva que podrian ir de manera simplificada en una sola vez (de hecho una de las evoluciones en HTML5 es la simplificación del uso de etiquetas); ahora no se daros ejemplos, porque a mi cerebro le da mucha pereza memorizar nombres que no les da un uso practico, y soy un adicto a lectura (lamentablemente eso no me da mejor memoria); pero es una etiqueta de relleno, Ignacio Lirio se lo he visto comentar en varios tutos y en una kdd… pero estoy seguro que eso los fabricantes lo mejoraran.
Osea! si mañana Indesign hace un ebook sin código basura, con un etiquetación estandariza buena y opciones puntuales a la mano para cosas particulares en ebook, ¿quien va a estar pensando en ponerse a hacer webs, cuando la función del maquetador es estar centrado en la edición? ¡ojo! mi visión es ir más allá del ebook de texto corrido… este año hice 2 ebooks interactivos en epub3 con indesign, para una empresa que los esta usando en sus iPads. El problema del código va más allá de la aplicación que nos pertoque a nostros, esta en que el sector se decidad a tener estandares bien asentados. No ves un epub3 igual en la app iBooks que en otra ¿porque? porque el problema es que se sincronizen toda esta gente, W3C, fabricantes de soft, navegadores…
Disculpad que me enrrolle! Este tema del libro me apasiona. Abrazos.
Respecto a la experimentación con libros electrónicos, sean EPUB enriquecidos con JavaScripts o appbooks, quise te interese revisar el siguiente sitio: https://editionsatplay.withgoogle.com
Como bien lo dices, la estandarización en un proceso paulatino donde la diversidad de fabricantes habrán de cumplir con cada una de las especificaciones del W3C. Pero la vía de experimentación no se acota al EPUB, existe un gran universo de posibilidad si lo que se desea es hacer libros altamente interactivos: que sean aplicaciones. Para su creación lo más ideal es trabajar con motores de videojuegos como Unity 3D, Unreal Engine o Cocos2d-x, haciendo evidente que su proceso de producción difiere demasiado a los procesos tradicionales de edición, ya que su metodología de desarrollo es más afín a la creación de videojuegos.
En general, si bien el punto de relieve es el ebook estándar, en donde yace las grandes posibilidades de la era digital para el mundo editorial es precisamente en los libros que rompen con el paradigma de la página y la lectura lineal y en el cambio metodológico dentro de los procesos tradicionales de edición. ¡Hasta luego!
¡Gracias, Jesús! Efectivamente hacer un libro EPUB de buena calidad con InDesign es posible, dependerá mucho de cada editorial, prestador de servicios editoriales o autores independientes la manera en cómo hacer el EPUB. En Nieve de Chamoy y Perro Triste nos enfocamos a la producción desde cero, creación de scripts y más porque no tenemos necesidad de recurrir a software de maquetación para hacer nuestro trabajo (Nieve de Chamoy) así como buscamos vías experimentales de producción de libros que quizá puedan beneficiar los procesos tradicionales de edición desde una perspectiva del software y la cultura libre (Perro Triste).
Solo me gustaría hacer una pequeña corrección en cuanto la conversión a formato EPUB desde InDesign: no hay necesidad de hacer ningún ajuste si se usa InDesign de la manera más pertinente. La clave está en partir con documentos XML, en lugar de documentos de procesador de textos como DOC o DOCX, y vincular directamente una hoja de estilos CSS antes del proceso de conversión, en lugar de recurrir a los estilos de párrafo o de caracteres que InDesign nos proporciona. Ya lo veremos cuando tratemos la manera de hacer un EPUB desde esta herramienta.
¡Saludos!
Me uno a las felicitaciones por el trabajo de detallar el proceso desde cero. Y también me uno a la petición de Mariana de comentar la metodología de creación que seguimos otros profesionales:
https://www.linkedin.com/pulse/8020-alberto-gutiérrez?trk=hp-feed-article-title-publish
Un saludo.
Muchas gracias, Alberto, por la amabilidad de contar tu forma de trabajo con los libros digitales.
Quien mejor puede intercambiar opiniones es Ramiro; yo me alimento de lo que él debate con los demás porque llega un momento en el que me pierdo…
La semana próxima publicamos otra entrada sobre edición digital y estimo habrá más temas sobre los cuales hablar.
Un saludo.
Hola, Alberto, ¡claro que sí! En una futura entrada hablaremos de cómo a partir de un xml es posible trabajar con InDesign para libros en formato impreso o digital. Aunque varias de las generalidades ya las mencionaste en tu artículo, je.
¡Saludos!
Muy bien explicado todo el contenido sobre lo que es la edición digital como proceso y producto.