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.
Lo ideal sería un ambiente distribuido de trabajo que produjera el texto marcado desde el autor. Hablando de metáforas caducas, el procesador de texto no es otra cosa que una metáfora de la máquina de escribir (y muchos lo usan como máquina de escribir). El procesador de textos debe morir. Lo ideal sería un sistema cercano a Wordpress, en el que que el libro se marcase desde su creación. ¿Qué formato sobrevivirá en el futuro? No sabemos, pero si el libro está bien marcado, no tiene por qué importarnos.
ResponderEliminarPero mientras ese sistema no exista o sea de uso común, como varios editores me han señalado, con razón, hacer ese "fork" donde tu propones es básicamente hacer el libro dos veces, lo cual implica multiplicar los posibles problemas en la producción por dos. Yo diría que de hecho por dos punto cinco.
Hola Juan Luis, muy interesante tu post, pero como trabajo en una gran editorial implicado en procesos de producción quería aclararte unos detalles.
ResponderEliminarEl primero es respecto al uso de InDesign (o Quark). Puesto que el core del negocio sigue siendo en un 95% libros impresos nadie se plantea ahora mismo dejar de usar estos programas puesto que el InDesign es algo más que un simple programa de maquetación. Ofrece un tipo de justificación inteligente que ahorra mucho trabajo de correcciones posteriores. Por lo tanto, el trabajo no solo consiste en "producir PDFs", la edición española, muy cuidadosa con los detalles, le preocupa mucho el diseño de sus contenidos y estos programas ofrecen los mejores y más eficientes resultados.
Por lo tanto, puesto que estos programas son imprescindbles, lo más eficiente es elaborar una maqueta que permita múltiples salidas (PDF, ePub, HTML). Las grande editoriales, con ese fin, han comenzado a implementar flujos de trabajo basados en archivos XML mediante gestores de contenidos. Esto permite elaborar una maqueta, que al ser un archivo XML, permitirá darle el uso (y reutilizarla) que se quiera.
Lo interesante del asunto, es que una pequeña editorial, usando también el InDesign y un procesador de texto, también podría emular estos procesos sin necesidad de implementar el gestor.
Te aseguro que a partir de todas las mediciones realizadas (y calculados los costes) este es el proceso más eficiente.
Juan Luis, como ya hemos comentado en twitter, el uso de indesign es necesario porque, como te comenta Gonzalo, todavía los libros siguen yendo principalmente a papel, por lo que es más eficiente preparar el libro en papel y exportar a ePub. El problema no es indesign, sino el que no se piense en diferentes salidas cuando se maqueta. Si el texto en indesign está pensado para exportarlo tanto a PDF como ePub, no hay demasiados problemas, el uso de estilos en Indesign (que muchos maquetadores no usan o usan poco) permite una salida muy acertada a formato ePub, pero es que además si se quiere trabajar con XML basta con etiquetar el texto desde indesign para poder exportar el texto en XML que se puede integrar después en otros procesos. Una maquetación correcta, un uso adecuado de los estilos y si se quiere un etiquetado xml del documento permite que indesign sirva para algo más que para generar PDfs. Lo cual no quita que lógicamente hay que tocar el código del ePub si se quiere una versión profesional de un texto que se va a vender y por la que el lector exige una calidad. Como te comenté ayer, el formato ePub y los lectores que soportan Adobe Digital Editions, permite la incrustración de diferentes fuentes (la fuente va encriptada para evitar que un usuario pueda descomprimir el epub y cogerla) por lo que en un mismo ePub se pueden usar diferentes fuentes. El tamaño de letra lo elige el lector, pero elige tamaño relativo en base al cual todos los tamaños de fuente se redimensiona, es decir, que no tiene porque haber un mismo tamaño de fuente: hay una fuente para títulos, para texto, para notas, etc. Se pueden usar separaciones de página (usando la separación de capítulos que obliga a que el siguiente contenido pase a página siguiente), la mayoría de los ereader soportan bloques y cajas a los que se les puede dar formato (margenes,etc) e incluso color de fondo (normalmente un tono de gris) por ejemplo muy usado para destacados dentro de un libro, etc.. Por supuesto el XHTML y sobre todo las CSS que soportan la mayoría de los lectores son limitados, no se pueden usar capas flotantes, por ejemplo, y todavía hay muchos errores de intepretación, etc que hacen que muchas veces nos volvamos y sobre todo como pasaba en los tiempos de web Netscape vs. Explorer hay que tener en cuenta que no todos los lectores van a interpretar igual. Lo que te quiero decir es que la versión ePub no tiene por que ser solamente un texto corrido (¿para qué entonces servirían que interpretase css?) y que se pueden hacer cosas más o menos vistosas . Pero sobre todo es que la cosa va avanzando, los lectores de mañana seguramente soportarán mucho mejor las css, empezará a haber color, etc. etc. etc y por tanto tenemos que pensar también en eso, y en el hecho de que no todo los ePub se lee en un ereader sino en ordenadores, tablet, etc.
ResponderEliminarPor supuesto que los procesos editoriales son mejorables, y que en el futuro seguramente habrá nuevos pasos o pasos que se eliminen, sobre todo si el libro electrónico toma un papel más importante que actualmente, pero ten en cuenta que la maquetación implica crear un texto adecuado para su lectura y que es un paso tan necesario en papel como en ePub, y para la mayoría de las editoriales que están empezando a digitalizar sus libros la forma más práctica sigue siendo el paso desde la versión pensada para papel (entre otras cosas, porque es la más correcta, piensa que muchas veces se meten correcciones incluso en imprenta en el último momento, no hay muchas veces un texto word con todas las correcciones, sino que la última versión correcta es la maqueta, y con un poco de suerte el fichero indesign). ¿Hay que mejorar? Por supuesto, y como te dice Gonzalo hay grandes editoriales que han implementado otros sistemas, pero en España lo que más hay son medianas y pequeñas editoriales a las que no les puede compensar dar el salto a esos procesos.
¡Ups!Perdona, Silvano por cambiarte el nombre a Gonzalo.
ResponderEliminarJuan Luis, deberías poner los enlaces a las versiones ebook del artículo al principio del mismo. De lo contrario ya lo habremos leído antes de verlos ;)
ResponderEliminarUna puntualización. En Kindle los libros pueden incorporar tipos de letra diferentes a los que usa la plataforma por defecto.
@René: ¿Qué es "hacer el libro"? Es una pregunta con mucha enjundia, y lo que hay que dilucidar es si se refiere al continente o al contenido
ResponderEliminar@gozque: En ningún momento he hablado de dejar el software de autoedición implantado en cada editorial, ni en general de cambiar los estudiados procesos de la producción del p-book. Lo que digo son dos cosas:
1) el fork entre p-book y e-book debería ocurrir ANTES de indesign y la producción del e-book debería llevarse a cabo con un producto específico. Por lo que comentan otros lectores de tu gremio, un epub producido con InDesign necesita bastante trabajo manual y, al menos, parte de él es evitable. Lo que digo es mantener el coste del empleo de InDesign en papel y abaratar el coste de la producción del ebook pasando de procesador de texto a herramienta específica.
2) el e-book demanda la primacía del contenido (a mi modo de ver), y eso se consigue dando más valor a las tareas de edición previas a la maquetación y centrando la producción del epub en conseguir un documento consistente, sin un sólo error de conversión, en todos los ereaders. Eso se consigue con el ePub lo más sencillo posible, prácticamente sólo estructura.
@Valentín al igual que le comento a Silvano, la eficiencia deriva de la adecuación de la herramienta y del grado de automatización de la conversión (o es inversamente proporcional al tiempo que hay que echarle).
ResponderEliminarSi la estructura del texto se aporta antes (e.g., si la versión final del texto estuviera en HTML mondo y lirondo, con tags de cabeceras, formato de carácter y muy poco más, y con cada título de sección, cita, diálogo con la etiqueta que le corresponde) de pasar a generar el continente, la generación del epub es trivial, y no se aumenta el trabajo de maquetación con el software de autoedición. Partimos de la base de que el texto llega de forma no correcta desde el autor, marcando los elementos estructurales a manopla, sin ningún tipo de uso de estilos.
Hace 120 años, mi bisabuelo escribía así, y se lo mandaba al impresor para que éste construyera el continente. Pero tanto el autor como el o los responsables del texto antes de llegar a maquetación podrían estructurar el texto, dado que es un trabajo trivial que va a ahorrar muchos dolores de cabeza después. Si el autor es "de letras", se puede estructurar el texto dentro de las tareas de proofreading y tenerlo listo para convertir a epub en cuanto se congele la versión final.
Lo que dices de los tamaños de fuente se corresponde con lo que acabo de comentar. P.e. en LaTeX tienes un tamaño de fuente predeterminado. Puedes cambiarlo a más grande o más pequeño en la definición de la clase de documento, y todos los estilos de la clase cambiarán de manera acorde.
De igual manera, la estructuración definirá qué es una cita, qué es una sección, y cada elemento mantendrá una forma reconocible a lo largo de todo el texto. El problema actual, como dije, es que una parte del parque de ereaders es tan rústico que lo vas a tarar a poco que juegues con CSS.
Sigo...
Hay un problema que no tenéis en cuenta y es que ePub es un quiero y no puedo. Quiero, porque permite recursos de maquetación elaborados... y fuera del alcance de muchos ereaders. No puedo, porque ePub es incompleto y no tiene implementado el marcado y el anotado, entre otras funcionalidades indispensables
ResponderEliminarFinalmente, respecto a los recursos de las pequeñas y medianas editoriales: efectivamente su core ACTUAL es el papel, pero una inversión moderada en implementar soluciones libres o gratuitas para ePub y mobi podría ser una inversión muy atractiva.
En cualquier caso, me quedo también con los comentarios de Uklanor - http://tinta-e.blogspot.com/2010/08/acotaciones-sobre-libranda-en-su.html#157884752982427612 , en el sentido de que a día de hoy la conversión desde InDesign no está libre de bugs ni mucho menos.
@Ernesto: pondría una parte no esencial de la mano en el fuego porque al usuario de Kindle la fuente le va a importar realmente poco. Lo que le va a importar es disfrutar de las ventajas del dispositivo, porque el dispositivo, el continente físico, va a ser siempre el mismo.
ResponderEliminarY por cierto, habrás visto que he tomado buena nota de tu sugerencia. Thanks!!
Desde mi punto de vista de simple lector empedernido, lo de maquetar un elibro me parece una locura. Mi iLiad tiene 8,1 pulgadas, la mayoría de los modelos tienen 6, otros tienen 5, y otros cerca de 10. Peor aún, aunque a algunos les asombre, el iPhone, con sus 3,5 pulgadas, es una plataforma de lectura ampliamente usada, y yo he leído varios libros con comodidad en mi móvil de 2. En cuanto a disponibilidad, el móvil es imbatible, siempre lo llevas encima.
ResponderEliminarAsí es que os lo voy a explicar en 2 palabras: no podéis. Es imposible hacer algo que se pueda llamar "maquetar" cuando se va a estar viendo en pantallas que van de las 2 a las 10 pulgadas, y con vaya usted a saber qué geometría (el ratio 3:4 no es precisamente universal).
Podéis seguir buscando el Santo Grial, una búsqueda eterna que os ennoblecerá, pero lo peor viene ahora. No es sólo que no lo vayáis a encontrar, es que los lectores no lo vamos a apreciar.
Como lector yo sólo quiero leer el libro. Punto y final. No quiero más. Y, desde luego, no quiero que el libro haga "cosas raras" por algún oscuro problema de compatibilidad, o por algún inesperado efecto que sólo surge con determinadas pantallas que resulta que la mía es una de ellas.
Me diréis que todo consiste en ser muy listo y muy trabajador, que los problemas están para arreglarlos, y que los futuros modelos de lector y las no menos futuras versiones del soft superarán las carencias de los actuales. Pero es que... como lector yo sólo quiero leer el libro. Punto y final. No quiero más.
Me parece tan absurda la idea de maquetar un elibro como la de enjaezar los caballos de un diésel. Comprendo que para algunos no sea fácil de asumir, pero es posible que todo este empeño en maquetar lo inmaquetable, en construir un sueño que ni siquiera es deseado, no sea nada más que la incapacidad de admitir que el oficio propio ya no es necesario.
Le dijo un editor a un maquetador: "Toma, aquí tienes el Word del libro". El maquetador preguntó "¿Cuál es el alto y el ancho de la página?" El editor contestó "No tengo ni puta idea". Y tanto que no tenía ni idea, lo que le debería haber contestado es que no hay páginas.
Entiendo que la postura que comenta Krigan se parece mucho al empeño que pusieron, y aún ponen, las compañías de cine al colocar muchos extras en los dvds y blu-ray( Manteniendo, de paso, un precio artificialmente alto). ¿ Cuanta gente realmente los veía? El tema de las descargas de películas(.avi antes y .mkv ahora) en sitios "alternativos" y redes p2p ha demostrado de sobra que el usuario final lo único que quería era ver "su" película, y nada más. Igual que lo que dice Krigan de que él sólo quiere leer su libro, y nada más. Igual a las editoriales no les conviene pretender un producto final "perfecto" al menos al principio, so pena de repetir idéntico error que disqueras y moviemakers....
ResponderEliminarPorque es evidente que el coste de tan excelsa maquetación hay que clavarlo en alguna parte. Pero no olvidemos que desde nuestro punto de vista, los lectores, los usuarios, los "clientes" del negocio editorial, los precios de los ebooks los percibimos "caros" ( Y me refiero al precio de venta, evidentemente, que ya conocemos que el coste de producirlos puede ser elevado). Si se trata de ganarle la batalla al p2p, cualquier cosa por encima de 6 a 10 € le va a sonar caro a los usuarios. Y si nadie te compra tu producto, no tiene negocio, por muy bonito que lo hayas maquetado. Un ejemplo: las ediciones institucionales de p-books, por ejemplo, son un perfecto ejemplo de despilfarro. Muchos fondos de gobiernos, ayuntamientos, diputaciones, universidades, etc, algunos con un gran trabajo editorial detrás, acaban siendo vendidos de saldo a libreros de viejo y ocasión. Y mientras tanto el coste de producirlos( que no suele ser poco), y el de almacenarlos, sale de los presupuestos, que salen de nuestros impuestos. ¿Vale la pena en la época digital se comience precisamente intentando que los inicios sean con calidad y precio altos?.
saludos.
«@René: ¿Qué es "hacer el libro"? Es una pregunta con mucha enjundia, y lo que hay que dilucidar es si se refiere al continente o al contenido»
ResponderEliminar¿Qué tanto se puede separar? Cómo se presenta la información es tan importante como la información que se presenta. Y si bien la realidad, como bien señalan, es que el 95% es impreso, para sacar verdadera ventaja del ebook tienes que aprovechar las ventajas propias del medio.
@Juano: No se puede ganar la batalla al p2p porque esa batalla no existe. Si la elección es entre cualquier cosa y gratis, siempre vas a escoger gratis. El precio no tiene nada que ver. La clave es la comodidad: puedo comprar un libro y leerlo, cualquier libro, en 30 segundos desde mi Kindle o puedo pasar desde 20 minutos hasta semanas buscando el título crackeado que quiero, rogar porque haya seeds en el torrent, ver si no es un fake o un scan mal hecho, conectar el kindle a la computadora... ¿qué voy a escoger?
Yo soy de los que cree que la misión de un editor es dar al lector el mejor texto (no me refiero a la calidad, que también) y en la mejor forma posible que permita una adecuada y agradable lectura, tanto en papel como en digital, lo cual a algunos lectores puede que no les importe pero la mayoría creo que lo agradecen, eso explica que haya diferentes ediciones del mismo texto con diferentes calidades editoriales y que ambas tengan su tipo de comprador. En relación al libro electrónico yo creo que el lector se merece igualmente una adecuada maquetación (que consiste precisamente en que independientemente del dispositivo que se use, las pulgadas, la resolución, el texto sea perfectamente legible y con un adecuado formato, cosa que es precisamente lo que persigue el formato ePub). Cpmo ejemplo adjunto dos pantallazos, uno de un libro electrónico que se ha formateado para buscar una presentación adecuada y que se vende comercialmente en diferentes librerías virtuales y que podéis ver aquí (http://www.ediciona.com/version_en_formato_epub_de_el_libro_de_angelina-dirpi-31525.htm?keepThis=true&TB_iframe=true&height=500&width=960) y otro de un best-seller que alguien ha convertido a epub y ha colgado en una red p2p y que podéis ver aquí (http://www.uploadfilesystem.com//viewimage.php?file=/imagenes/10/09/03/H5J08408.jpg): ¿Cuál de los dos creeis que permite una mejor experiencia de lectura? Los editores nos empeñamos en hacer libros bien hechos, tanto en papel como en ebook porque creemos que la mayoría de los lectores apuesta también por ello.
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminar¡Qué lástima no haber podido meter baza en este y los dos anteriores (por motivos de trabajo: cuando uno está moviendo cajas 16 horas al día, cuando llega a casa sólo quiere hacer una cosa: mimir)!
ResponderEliminarMe gustaría puntualizar un par de cosas que han salido por aquí (en los últimos posts). Es de agradecer que profesionales del sector expliquen las dificultades con, por ejemplo, el InDesign ese, que tiene que ser la rehostia de programa pero creo que mal enfocado, aunque lo más seguro es que sea mal usado. Entiendo todo eso de los marcos, de formatear "para ver", etc, pero considero que si el "formateo para ver" está bien hecho, el "formteo para fluir" debe ser inmediato. Claro, que si se fuerzan anclajes "duros", luego viene el problema, problema que también estará presente cuando se decida hacer una edición del mismo libro en otro tamaño. Entiendo que si una caja viene después de un párrafo, si la caja está "anclada" a ir después del párrafo, cuando ese párrafo se mueva a otro sitio, la caja "fluirá" detrás de él. Si las viudas y huérfanas se deciden a nivel de documento en lugar de ir recorriendo el texto para ver en qué página hay una y corregirla "a mano", cuando el nuevo formato cambie el tamaño de página, el programa "corregirá" dichos párrafos. Si lo ponemos a mano, pues habrá que quitar la anterior y añadir la nueva... y ahora es donde supongo que dichos programas sean capaces de controlar todo eso automáticamente, lo que en conjunción de un buen "formateador" hará la tarea sencilla. Si un programa de ese tipo no es capaz de hacer eso, mejor mandarlo a freir espárragos y usar otro.
Otra cosa de la que se ha hablado es la diferencia de precio entre el libro de papel. En el ejemplo se ponía una diferencia sólo de 6 euros. Veamos dos falacias (sigue en el comentario siguiente):
Este comentario ha sido eliminado por el autor.
ResponderEliminarLa primera: ¿Valen 6 euros el papel, el comprar y mantener dicho papel en un ambiente controlado, el mantenimiento de la rotativa o de lo que quiera que se use para construir el libro, el cartón de la tapa y el mantenimiento de la máquina que encuaderna, más las amortizaciones correspondientes, más los sueldos de los que mantienen el almacén de papel, los que usan las máquinas citadas, más el coste del almacén en donde se guarda el libro, más el coste de las personas que manejan ese almacén, más el coste de enviar y repartir el libro a las librerías, más el coste de las personas que realizan ese trabajo? O en otras palabras, si todo eso vale 6 euros, suma la mísera cantidad que cobra el autor, quita el 10% que se lleva la librería al vender el libro, y lo que queda es la escandalosísima cantidad de dinero que se quedan el editor y el distribuidor...
ResponderEliminarLa segunda, con un ejemplo de un libro, Anatema de Neal Stepehenson, que vale 30 euros. En usa vale unos 10 dólares. Valiendo 10 euros, la diferencia entre USA y aquí es de 20 euros. Por 3.000 ejemplares, 60.000 euros. ¿Valen los derechos de autor 30.000 euros y el traductor cobra otros 30.000? Me hago traductor ahora mismo. Porque en USA se venden más, pero hay más quilómetros para repartir los libros, y en esos 10 dólares/euros el autor ya cobra, y los sueldos para hacer el libro también son más altos que los de aquí, etc... Lo siento, no me cuadra.
Valentin, el segundo ejemplo tiene pinta de ser una conversión descuidada. Normal. El ejemplo de minotauro digital podríamos traducirlo en seudocódigo así:
ResponderEliminar[imagen]Alejandria.png[/imagen]
[cabecera de nivel 2]De como Angelina llegó a Alejandría sana y salva en un barco portugués[/cabecera de nivel 2]
[párrafo]El [itálica]Boa Ventura[/itálica] arribaba al puerto de la Xania en Candía...
...carta de su padre[/párrafo]
[cita]Mi querida niña...
...[/cita]
[párrafo]SIGUE EL TEXTO[párrafo]
Con esa estructuración se aseguraría que el texto se viera correctamente en todos los ereaders. La experiencia de lectura sería irreprochable. Si se jugara más con las especificaciones de ePub, se empezarían a correr riesgos de que no se renderizara siempre bien, y no se obtendría ninguna ganancia palpable en la experiencia de lectura.
Juan Luis, pues eso es precisamente, el libro va estructurado con etiquetas XHTML, y luego se le aplica una hoja de estilo que permite ciertas cosas en según que ereader, pero en cualquier caso el texto ya está estructurado y se puede visualizar en todos los ereaders. moviles, etc que soportan ePub. En algún momento hay que estructurarlo, y si ya lo has hecho para papel usando estilos de indesign pues al exportarlo a ePub hay mucho menos que corregir, aunque evidentemente siempre hay que tocar algo de código, pero en hacer una novela de 300 páginas, puedes tardar muy poco tiempo en hacer un buen trabajo. Si en vez de partir de indesign partes de un word, también alguien habrá tenido que estructurarlo, y organizarlo (y te puedo asegurar que no va a ser el autor) con lo cual si lo haces dos veces (word para ebook e indesign para papel, porque para papel neceistas un programa de maquetación profesional y no te vale con word) es menos eficiente que si solo lo haces una, porque si exportas desde word, por muy bien que esté el fichero, también tienes que tocar en sigil el código del ePub, si quieres darle un buen acabado. Conclusión (desde mi experiencia) siempre que se tenga la versión indesign de un libro, es más eficiente, se tarda menos tiempo y el resultado es mejor, que partiendo de cualquier otro formato (Claro que si tienes un libro de texto corrido en word bien hecho y el mismo en indesign mal hecho, seguramente será mejor partir del word, pero en general la versión mejor preparada es la de indesign) Por supuesto que hay que corregir cosas en el ePub, pero como te digo también hay que hacerlo desde cualquier otro fichero y el resultado inicial del que partes es peor.
ResponderEliminarValentín, cito el comentario de uklanor de hace unos días:
ResponderEliminarhttp://tinta-e.blogspot.com/2010/08/acotaciones-sobre-libranda-en-su.html#157884752982427612
[cita]Maquetar un ePub de calidad en In Design da bastante más trabajo que simplemente “convertir a un formato reflowable”, de hecho en la mayoría de los casos es mucho más complejo que maquetar el libro equivalente en papel, de hecho es una maldita pesadilla. En maquetación para papel In Design se comporta perfectamente, lo que ves es lo que finalmente obtienes, en más del 90% de los casos, en el caso de ePubs ni lo que obtienes ni es lo que ves, ni lo que intuyes, ni mucho menos lo que pensabas conseguir. A pesar de que en la versión CS5 se ha mejorado sustancialmente la exportación a ePub respecto a versiones anteriores de In Design, hay que estar lidiando con los estilos y con los cortes de palabras para que se comporten realmente cómo se pretendía. Y después toca rezar, pues, -heredando los problemas clásicos de HTML/navegador-, nos enfrentamos con las inconsistencias de representación de los e-readers. No hay forma (al menos no hay forma sencilla) de que el ePub se vea exactamente igual en todos los e-readers y prácticamente siempre hay que acabar retocando con Calibre o rascando directamente a mano el código CSS para llegar a la mejor (o menos mala) solución de compromiso. Y estamos hablando de libros de texto corrido (novelas y similares), si estamos hablando de intercalar imágenes, esquemas, tablas, fórmulas o diagramas de forma coherente entonces agárrate que vienen curvas. Y por supuesto, luego explícate ante el cliente que no entiende porqué en su ebook o erevista en ePub no aparece esa composición tan “de diseño” o esos contorneos irregulares que tan bonitos quedaban en la versión PDF. Eso sin contar que en los más de los casos vale más la pena volver a maquetar desde cero el libro que intentar re-aprovechar una maqueta de In Design pensada para impresión.
Créeme que si en algún lugar hay que ahorrar costes en la comercialización del ebook desde luego no es en la fase de maquetación. Yo personalmente me alegro de haber pasado, al estilo de Dante, por ese infierno y haber permanecido en él una temporada pues por lo menos he aprendido bastante cosas, la primera y más valiosa, que no me quiero dedicar nunca más a la maquetación ePub.[/cita]
He preferido citar a alguien con experiencia directa en indesign y ePub. Viendo los problemas que introduce epub en la conversión, me reafirmo en mi idea de que el fork entre ebook y pbook se debería hacer antes.
Juan Luis, no dudo de que esa sea la experiencia de uklanor, pero la mía es muy distinta, y llevo unos cuantos ePub a mis espaldas para editoriales muy diversas. Por supuesto que no es un trabajo sencillo y que precisa de conocimientos de XHTML y CSS si se quiere hacer bien, pero esto es igual que si alguien quiere exportar desde word a página web y que le quede una web profesional, pues evidentemente no lo va a conseguir. Un lector puede convertirse un libro con calibre para su lectura personal, pero una editorial necesita un profesional que le de un producto bien acabado y eso siempre lleva algo de trabajo (insisto se parta desde cualquier tipo de fichero), y si hablamos de libros complejos que incluyen gráficos, tablas, notas al pie, bibliografía, etc. ya ni te cuento. La discusión que estabamos teniendo es si tiene sentido partir de indesign para hacer un ePub, mi experiencia es que si el libro tiene un mínimo formato (que se quiera respetar en la medida de las posibilidades del epub y los ereaders) es la opción más fiable. Por supuesto tienes que tener conocimiento de XHTML y CSS pero también de indesign para retocar lo que sea necesario (especialmente la aplicación de estilos, sobre todo de caracter) para que la exportación sea más correcta. ¿Qué lleva trabajo? Por supuesto, si la conversión fuera automática, no habría ningún problema, pero es que no hay ninguna conversión automática que sea 100% efectiva.
ResponderEliminarValentín, de hecho mi comentario venía a colación de una afirmación de Juan Luis en la que venía a decir que transformar un documento in Design a un formato reflowable era muy fácil (de "mandriles" decía exactamente). Yo lo que replicaba es que para nada se trataba de un trabajo fácil -tal cómo tú mismo afirmas- (al menos en un ePub con aspecto profesional) y que por tanto no era en ese punto donde debía centrarse el abaratamiento la cadena de producción (por desgracia muchos editores son de la misma opinión que Juan Luís). Ahora bien, a lo que sí le doy la razón a nuestro anfitrión es que, en depende que libros, la maqueta de in Design debería colocarse más hacia al final en la ecuación, partir de un texto bien estructurado y luego bifurcar para electrónico (con inDesign o con otra herramienta más apropiada) y para papel ( ahí sí con inDesign sin niguna duda). Coincido contigo no obstante que en otros casos, sobretodo de libros con unos requerimientos de formato mayores, el formato in Design es el más fiable como punto de partida ...pero asumiendo todo el trabajo de prueba y depuración posterior que muy probablemente habrá que realizar.
ResponderEliminarResumiendo, teniendo en cuenta la nueva realidad de los flujos de trabajo, debería haber alguien en la cadena de producción, después del autor y antes del maquetador, que decidiera que estrategia seguir en cuanto a edición de ebook se refiera dependiendo de las características "semánticas" de la obra en cuestión. En muchos casos la mejor opción probablemente sea inDesign, pero no estoy muy seguro de que lo sea en otras y por tanto deba optarse por alguna herramienta de software alternativa.
De todos modos, tal y como afirmaba en el último comentario del anterior post, no sería nada extraño que Adobe añadiera prestaciones WYSIWYM en futuras versiones de ID.
Para Valentín:
ResponderEliminarCreo que trampeas con el segundo ejemplo. No es que esté mal maquetado, sino que el texto en sí es un churro. Para hacer una comparación en condiciones tendrías que poner un texto correcto, y ya de paso que estuviera dividido en párrafos. ¿O es que los escritores redactan sus textos sin párrafos?
Así la gente podría comparar y posiblemente muchos pensarían "sí, vale, ese gráfico de Angelina es muy chulo, pero eso de meter un gráfico entre 2 porciones de texto (o al comienzo del mismo) también se puede hacer en Word. Además, el texto [correcto] de Millenium no se lee nada mal".
En cuanto a tu primer ejemplo, lo siento pero opino que ese texto maravillosamente maquetado no se verá bien en muchos lectores e-tinta. Para empezar, el título de capítulo está en color azul, pero los cacharros e-tinta no soportan color, sólo escalas de gris (16 si tienes suerte). Así que el título se verá en un desvaído tono de gris (en efecto, he sufrido esa clase de títulos mal hechos en alguna ocasión).
Por otro lado, el texto de la carta es de un tamaño de letra más pequeño que el texto principal, y está "desplazado" a la derecha (un programador diría indentado, no sé qué término usaréis vosotros). En mi lector de 8 pulgadas, como le metas más de 10-12 palabras por línea ya vas a ver el texto demasiado pequeño como para que se lea con facilidad, y el desplazamiento ocupa el tamaño de 2 palabras cortas o una larga. Así que la carta (letra pequeña) va a estar teniendo 8-10 palabras por línea (con menos sería difícil de leer), y el texto principal (letra grande) tendrá unas 4-6. Como además el texto principal está justificado, prepárate para que las palabras que sean especialmente largas te dejen hecha un asco la justificación de la línea en la que están.
Eso en un lector de 8 pulgadas. En uno de 6 el efecto será más acusado, y todavía peor en uno de 5. No te digo ya nada si el libro se lee en un iPhone. En otras palabras, en pantallas pequeñas, cosas tales como el indentado y usar diferentes tamaños de letra son una Mala Idea. Para que el lector distinga con comodidad el texto de la carta del principal te hubiera bastado con usar cursiva, lo cual no da problemas.
Ahora mira cómo se hacen las cosas con el Kindle:
https://wiki-land.wikispaces.com/Kindle
Sencillo, razonablemente bonito, efectivo, y sin problemas.
Uklanor, efectivamente creo que estamos de acuerdo y por lo que veo nuestra experiencia es en el fondo similar: hacer un ePub conlleva un trabajo de ajuste que no es en absoluto desdeñable y que en según que casos puede ser bastante complejo, y efectivamente en libros con escaso formato, puede funcionar bien partir de un fichero de texto si está bien formateado.
ResponderEliminarRespecto a KRIGAN, comentarte que el ejemplo de Larson que he puesto sí tiene parrafos, lo que sucede es que se le han colado los encabezados, y a veces no hace bien la separación. Si has probado alguna vez a convertir desde PDF verás que aunque los parrafos estén claramente marcados, dadoque PDF está pensado preferentemente para imprenta y no para ser fluido, a menudo la partición en parrafos que hace, por ejemplo, Calibre, es bastante imprecisa. La mayoría de las veces partir de un PDF es bastante desastroso, precisametne por eso, porque no es facil dividir automaticamente parrafos, eliminar pies y encabezados, etc. En cuanto a lo que comentas, el título se ve en azul porque es un enlace (al índice) es algo que hace automáticamente algunos lectores (no tieen puesto un color, sino que según el lector, colorea los enlaces de un color, normalmente en azul, o morado si ya se ha visitado, etc), pero en un ereader con tono de grisis se verá en el mismo color que el texto. Respecto a indentados y demás, están hechos con hoja de estilo, es decir, el código XHTML no tiene nada que produzca ese indentado ni ese tamño de fuente, sino que todo está hecho con CSS. Esto significa separa contenido de diseño, de esa forma cuando tú lees este libro en un dispositivo como un teléfono móvil que no soporta css, no verás indentados ni demás. Este mismo ePub abierto con stanza tiene otro formato distinto. Esto quiere decir que no porque haya dispositovos que no soportan CSS o tiene una resolución menor, tenemos que renuncia a presentar los librosde forma más vistosa para la mayoría de los lectores. Te pongo como ejemplo los navegadores web, hace algunos años, hay cosas que solos e pueden hacer para unos navegadores y no para otros, y lo que se hace es preparar la web de tal forma que se aprovecha el potencial de algunos navegadores pero no impidiendo que otros navegadores visualicen la web, sino que no dispongan de ese efecto sin dificultar para nada la lectura navegación, etc. Lo contrario sería simplemente hacer los textos planos pensando en los que lo leeran con dispositivos menos avanzados. Es mejor aprovechar lo más avanzado, pero permitiendo que los menos avanzados accedan al texto tal cual.
Se me olvidaba comentar que todos los tamaños que se usan son relativos por tanto el indentado será más pequeños cuanto más pequeña se la pantalla, esto hace que una pantalla pequeña en caso de que se visualice el indentado este será muy pequeño, pero lo suficiente para notar un cambio de formato, mientras que en una pantalla más grande, lógicamente el indentado será mayor. No se usan tamaños absolutos cuando se maqueta un ePub y por tanto todo es relativo al tamaño de pantalla, resolución y el tamaño de fuente que elija el usuario, evidentemente si el usuario elije un tamaño de fuente XXL probablemente el formato no se visualizará en absoluto, pero es que en ese caso el usuario prima el ver la fuente grande sobre cualquier otra consideración, y eso es también es una ventaja de los ereaders y una prerrogativa del usuario.
ResponderEliminarPara Valentín:
ResponderEliminarMe alegra ver que estás haciendo las cosas bien por ese lado, pero si quieres hacer una comparación justa tendrás que poner pantallazos de cómo se ve en un lector e-tinta un texto correcto sin maquetar (tan sólo con un poco de formato html), y cómo se ve en esa misma clase de aparato un texto maquetado. Si resulta que la gente ve que no hay diferencia, ¿para qué van a querer un texto maquetado?
Y por supuesto, en ambos ejemplos debería haber un gráfico o no haber ninguno. Si resulta que en uno hay un gráfico chulísimo y en el otro no, ya estás planteando la comparación de una forma sesgada.
La idea, desde luego, no es convertir desde PDF, sino desde Word, y la cuestión que se debate es si la conversión ha de ser directamente desde Word o si es más conveniente maquetar primero (con InDesign o el que sea). Planteas que hay diversas clases de aparatos, y es cierto, pero a día de hoy los claramente hegemónicos son los e-tinta y los móviles. En ambos casos el tamaño de pantalla no da para muchas virguerías (la gran mayoría de los e-tinta son de 5 ó 6 pulgadas). Los e-tinta son en blanco y negro patatero (16 grises como mucho), y la pantalla de los móviles es todavía menor (casi siempre menos de 4 pulgadas).
Tal vez el iPad y sus imitadores cambien la cosa en el futuro, pero a día de hoy es así. Tu bonito maquetado se verá precioso... en el futuro tal vez. Suponiendo que en el futuro no usemos aparatos estilo PSP (pantalla mucho más ancha que alta), en cuyo caso el gráfico de Angelina será más un estorbo que un placer para la vista.
Pero, sobre todo, yo creo que hay algo profundamente equivocado en el concepto de maquetar un elibro. No hay páginas. Es importante, así que lo repito: no hay páginas. Un elibro es como uno de esos rollos de papiro o de pergamino de la Antigüedad, y encima un rollo del cual no sabes anticipadamente la anchura. Del WYSIWYG ya te puedes ir olvidando, y sin eso ¿tiene sentido hablar de maquetar?
Otra manera de verlo es considerar que el papel es "tonto" mientras que los aparatos de lectura son "inteligentes". En el papel, el maquetador va tomar decisiones tales como el largo y ancho de la página, el tamaño de los márgenes, el tamaño y tipo de letra, y un largo etcétera.
ResponderEliminarYa hemos dicho que en el elibro no hay páginas, pero sí hay anchura de pantalla, y eso lo decide el diseñador del aparato. También el tamaño de los márgenes lo va a decidir el aparato, lo mismo que el tamaño y tipo de letra. En muchos casos (tal vez todos) el aparato permite al usuario el cambiar el tamaño de letra. Además, muchos aparatos permiten rotar la pantalla, por lo cual el usuario puede elegir entre 2 anchuras distintas, y los márgenes lógicamente también pueden cambiar, pero es que además la geometría de pantalla también cambia radicalmente de "más alta que ancha" a lo contrario, o viceversa.
El maquetador decide en el libro impreso si numera las páginas, y cómo las numera, pero eso pasa a ser cosa del aparato en el elibro, que lo mismo puede mostrar una simple barra de progreso, o un porcentaje de texto leído, además de otras opciones. También está el color de letra y de fondo, el interlineado, el cómo va a ser el salto de párrafo...
En definitiva, hay un enorme montón de decisiones que antes tomaba el maquetador, y que ahora decide el aparato, e incluso el usuario. Evidentemente, alguien tiene que decirle al aparato cuándo hay un salto de párrafo, cuándo las palabras están en cursiva, cuándo hay un título (de capítulo por ejemplo), pero ese alguien lo mismo puede ser el autor, el editor, o un maquetador que ya no haga lo que hasta ahora hemos conocido por maquetar.
Le podemos llamar "formateador" o "revisor de formato", o seguir llamándole maquetador, el nombre es lo de menos. Lo importante es que ya no estamos hablando de maquetar, ahora el que "maqueta" es el aparato. Las decisiones que quedan "antes" del aparato a menudo tienen que ver con el significado (esto es un título, esto es un párrafo) antes que con la presentación, incluso la cursiva se usa a menudo más en relación con el significado que con la presentación (esto es la carta del padre de Angelina).
Resulta que quienes suelen decidir sobre el significado son el autor y el editor, el maquetador de lo que se ocupa es de la presentación, pero ahora eso en gran medida lo hace el aparato. Por esto es por lo que digo que no es que el trabajo de maquetador haya cambiado, sino que en un elibro no hay nada que merezca llamarse maquetación.
@Rene, la batalla contra el p2p SI se da en el precio, de hecho es función de precio y conveniencia. Si el precio es elevado puedo renunciar a la conveniencia de Amazon e irme al p2p pero si el precio es reducido no me compensa la perdida de tiempo de buscar, descargar, convertir... Amazon gana.
ResponderEliminarDe hecho por debajo de los 3$ ni se plantea uno alternativas. Es compra por impulso.
Las cantidades varían, la función de utilidad percibida depende de otros factores, 9$ es un precio tope para una novela para un consumidor medio, pero para uno en un país en vías de desarrollo puede ser inasumible. Mientras que un libro técnico puede ser interesante por 15$. Todo depende del bolsillo del consumidor y la utilidad percibida.
Hay quien siempre ira al p2p, pero hay un precio aceptable para una mayoría, un precio para el que maximizamos las ventas aunque no necesariamente los ingresos ;-) y ESE es el problema.
Hola, conversación está muy interesante, aquí les dejo http://infotarget.com/2010/10/04/crea-tus-propios-libros-electronicos-para-tu-kindle/ los plugins para indesign para libros de kindle, aunque está para formatos mobi y epub también.. saludos
ResponderEliminar