jueves, octubre 07, 2010

Entrevista a Jaume Balmes (1)

Coincidí con Jaume Balmes en los comentarios a un post de nuestro común amigo RFOG. Me interesó tanto lo que comentaba desde la experiencia de la realidad de trabajar con ePub que le propuse hacer una entrevista por email, para profundizar en los aspectos que más me habían llamado la atención. Volvimos a coincidir hace pocos días, de forma inesperada, en el coloquio de editores y libreros en el que participé el pasado sábado.

Los resultados han superado mis expectativas, porque desmitifican bastante del tema en cuestión, sobre todo si se le enfrenta con la mirada limpia y sin pasión - yo también tenía mi cuota de errores al respecto.

Gracias, Jaume, por el esfuerzo, el tiempo y la claridad obtenida. Espero que con la publicación de esta entrevista se aclaren buena parte de las dudas que muchos teníamos respecto a los procesos actuales que implican la creación de ePubs

He dividido la entrevista en dos partes, por su longitud. Sin más, os dejo con la primera:

Hola, Jaume:
En tu comentario en el blog de Kindleman se notaba a las claras que hablabas con conocimiento de primera mano, y que no tienes pelos en la lengua (como si los pueden tener otra gente del ramo que habla respecto al "coste de los epubs"... cosa que es de respetar, por otra parte). Por eso quería hacerte algunas preguntas, en principio para ampliar tu comentario en el post de RFOG y construir así una composición de lugar. Si te parece, me gustaría publicar la entrevista en tinta-e tal cual.

Vamos al tajo:

1) ¿Es mucho más sencillo generar un libro-e desde cero que "remontar" o "desmontar" un libro-p hacia libro-e? Entiendo que sí, por lo que comentas, pero me gustaría que abundaras en este sentido.


1- Desmontar un libro-p no tiene excesiva dificultad, con un “pero”. Paradójicamente es mucho más sencillo y limpio desde Quark que desde ID, por una simple razón, que parece una tonteria, pero en el procesado y limpieza del html te ahora MUCHÍSIMO trabajo: en Quark puedes definir las cursivas y tipos bold “falsamente”, es decir, no como un estilo o una tipografía, si no como una propiedad del caracter, cosa que al traducir en html tienes unas bonitas etiquetas [em] y [strong], en vez de un estilo css [span class="cursiva"], por ejemplo). Esta tonteria ayuda mucho a limpiar estilos inútiles en el html fácilmente. Desde el ID eso no es así, y por lo tanto definir cada cursiva es definir una clase CSS concreta. Tengo que decir que estoy hablando de fondo editorial antiguo, con los vicios cogidos del papel. Me refiero que es más sencillo empezar desde cero, pero desmontando el archivo abierto del libro-p, ya que los Word iniciales no se pueden usar, ya que carecen de las correcciones de estilo, ortográficas y tipográficas. Lo que cuesta mucho más es limpiar un .epub hecho con ID en base a un libro-p, pensado y compuesto sólo para libro-p.

2) (dependiendo de la contestación a (1)): ¿Es mejor generar el PDF y de ahí el epub desde indesign, o lleva menos esfuerzo generar un epub desde el texto previo?

2- Te he respuesto en la anterior. Seria muchíssimo más fácil partir de un Word/ODT/RTF... pero no se puede usar al carecer de todas la correcciones posteriores a la composición. Te ahorras una buena limpieza de estilos.

3) Bajo tu criterio, ¿Hay mucha diferencia de coste entre maquetar un libro-p y un libro-e?

3- En el tema de los costes creo que no se puede establecer un paralelismo del coste de un mismo libro en papel y el ebook. Por norma general es más barato, pero un elemento tan tonto como las versalitas, que se pueden estilizar relativamente fácilmente en un libro-p, en un libro-e es un drama (el css de epub no acepta el atributo “smallcaps”). O sea que si es un libro con muchas versalitas, el libro-p puede salir más caro. Hay más ejemplos tontos que son un quebradero de cabeza para la composición de libros-e, por cuestiones que no se entienden (¿¿¿tanto cuesta actualizar el formato???).

4) ¿Podrías desarrollar lo que comentas en el comentario a RFOG sobre los resultados de InDesign para generar ePub?

4- Con el tema de los resultados del ID, sé que mucha gente no está de acuerdo conmigo, pero sigo defendiendo mi postura. Un libro salido de ID NO se puede (ni se debería) vender. Sé que en el sector de la composición de libros, acostumbrados a herramientas transparentes muy buenas, no quiere actualizarse a maquetar código, pero la calidad que los clientes se merecen lo necesita. Tocar el código es imprescindible, y hay muchos casos en que arreglar un xhtml (y el CSS, aunque se puede incorporar desde ID uno ya existente que lo evita) generado por ID es peor que sacar el texto con el mínimo formato y liarse con el xhtml. Sé que mi posición es un poco maníaca por que estoy obsesionado con que el código esté lo mas limpio posible (los que probéis vuestors epub con los Sony Reader sabréis lo que es no entender que pasa y remirarte el código, el tamaño de cada archivo, etc...), pero creo que eso te da la tranquilidad de que tu epub se va a leer en todos los dispositivos que lean ese formato.


5) ¿Qué te parecen los productos libres para generar y editar epubs, calibre y sigil?


5- A priori soy un defensor a ultranza del SL, yo estuve muchos años trabajando con GNU/Linux únicamente hasta que descubrí Mac OS X y vi que me podía olvidar de la informática de una vez por todas, y usar el ordenador como herramienta de trabajo y ocio sin preocupaciones (el Windows lo dejé de usar a los 16 años, pasando a usar Red Hat 7.3 si no recuerdo mal, y posteriormente Debian Potato, qué tiempos). Igualmente uso habitualmente OpenOffice (aunque tiene que mejorar mucho aún...) y otras herramientas de SL (incluso he donado bastante dinero, para mi modestíssima economía, en proyectos diferentes de SL). Dicho esto, prefiero esperar a que Tanto Calibre como Sigil tengan versiones realmente estables (cuando tengan la version 1.0) para emitir un veredicto. Hoy en día no són más que una pérdida de tiempo en lo que es la edición (¡¡¡y las constantes actualizaciones del Calibre me tienen de los nervios!!!). El Calibre puede ser útil como herramienta de conversión de formatos, pero nunca se puede usar en un entorno profesional sin el consiguiente control de limpieza de código posterior. En cualquier caso, la iniciativa es muy buena en ambos programas, y facilitará mucho la autoedición a nivel particular de documentos para leer en un lector-e. Y espero que realmente en algun momento, alguna empresa con dinero apueste por desarrollar ambos programas (considero un mito que sólo la comunidad puede hacer programas libres realmente funcionales más allá de un carácter de ocio y “frikismo”, todos los buenos programas de SL tienen una empresa multimillonaria detrás).


6) ¿Qué solución te parece la más apropiada en estos momentos, InDesign, Sigil o liarte con el editor de texto como los valientes?


6- Aquí te diré que depende. Profesionalmente me encuentro con el 90% de los libros-p que tengo que componer en libro-e en formato Quark, de manera que sólo me queda el código. Pero como he comentado antes, un ID no es tan fácil de desmontar, así que depende su complejidad puede salir mejor exportar un epub sin estilos (vaya, los suficientes como para no perder las cursivas y negritas) y empezar de cero, sabiendo que tienes dos formatos, como mínimo, ya definidos. Pero también puede interesar, en el caso de las notas al pie, conservar el enlace (entre llamada y nota) que se exporta correctamente des de el ID, incluso si la TOC es muy larga, y después arrglar el formato de las llamadas y las notas a pelo. El Sigil, por lo dicho antes, lo descarto, de momento, para entornos de producción.


7) ¿Puedes desarrollar lo que comentas sobre la necesidad de retocar imágenes y mapas?


7- A ver, el tema de las imágenes. Yo soy diseñador, me es natural el pensar cómo se va a ver una imagen en una pantalla (de ordenador, teléfono, netbook, etc...) o en papel (y sus diferentes acabados). Sólo hace falta añadir al esquema las pantallas de resolución “rara” que tienen los lectores-e, eso quiere decir que el grano es muy grande, que no tienes “antialiasing”, que los niveles de gris son muy limitados, etc... Y se trata de que la imagen se vea en todo tipo de dispositivos que leen epubs. Desde lectores-e de hace tres años, hasta la super pantalla (en términos de resolucion y calidad de imagen, comparado con los lectores-e) de un iPad. Eso implica que tienes que retocar contrastes, pensar que las líneas finas desapareceran (por lo tanto hacerlas más gruesas), etc. Y en el caso de los mapas, sobre todo hay líneas muy finas, se añaden muchas tipografías, y muchos tamaños. En muchos casos se tienen que hacer desde cero, renunciando a muchos topónimos (al hacer más grande la letra, no caben), doblando el tamaño de las líneas, e incluso partiéndolo en diferentes páginas (solución que odio, pero que piden).


8) ¿Por qué los editores piden ediciones y modificaciones que los ereaders actuales no pueden renderizar? ¿Me he equivocado al interpretar esa parte de tu mensaje?


8- Siguiendo con lo anterior, muchas veces, por coste, no se rehacen los mapas, y simplemente se aumenta ligeramente el contraste y se intenta “engordar” las líneas de algun modo sencillo. Eso hace que, en un iPad lo veas decentemente, pero en un lector-e no veas nada en absoluto. Esto no te lo hace el ID, tienes que hacerlo a parte, en todos los casos. Lo más fácil suelen ser las fotografías en b/n, sólo aumentando el contraste suele quedar un resultado muy bueno para todos los dispositivos.


Como comentario de todas mis respuestas, tengo que decir que se basan mayoritariamente en la composición de libros-e desde libros-p que NO han sido compuestos pensando en que en algun momento existirian los libros-e. Muchas de las dificultades que me encuentro en el dia a dia pueden minimizarse si la composición está pensada des de un inicio para salir en “p” y en “e”. También las buenas artes del taller que haya compuesto el libro-p. Me he encontrado libros que han doblado su precio sólo por tener preparar el Quark para la exportación, sin errores, del texto con formato (para hacer el epub desde cero)
.


En breve, la segunda parte de la entrevista.

Nota: disculpad (sobre todo tú, Jaume) el descabale de formato de este post hasta las 10:00am. Me dormí sin repasarlo del todo. Empiezo a hartarme de las pirulas de blogger con WYSIWYG, y eso que es un caballo regalado

18 comentarios:

  1. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  2. Una entrevista muy interesante, sí señor.

    Tiene mucha razón el señor Balmes con lo de los mapas, se ven como el culo en un ebook de EPD de 6 pulgadas. La chapucilla más útil sería imprimirlos en una hoja A4, cuando haya pocos, claro.

    Mucho se ha hablado de las limitaciones del ePUB como adalid de los estándares abiertos en los ebooks y de su glaciar velocidad de actualización del estándar. Me gustaría saber qué tal se comporta el malvado MOBI de Amazon con todos esas chorraditas no soportadas en el ePUB, aunque supongo que es un problema que no haya herramientas profesionales o amateur para maquetar para MOBI y que el estándar no esté bien documentado.

    Es curioso que el InDesign sea tan pejillero con los estilos, cuando Adobe no se cansa de gritar a los cuatro vientos lo bien que va su programa con los ePUB. Al final tiene que ser un dinosaurio como el Quark quien lo ponga en su sitio.

    Yo, como maqueto para mí mismo, puedo hacer lo que me dé la gana. Después de probar varias posibilidades, me decidí por maquetar en Word, eliminando todos los estilos chorras y propiedades inútiles de carácter y de párrafo. Dejo el ebook bien limpito y luego le aplico unos pocos estilos uniformemente en mis ebooks, que al ser ficción no tienen mucho formato. Al acabar, guardo como "Web (filtered)", que tengo entendido que quita mucha mierda del HTML, y convierto a MOBI con el Calibre. Estoy muy contento con los resultados en mi Kindle.

    ResponderEliminar
  3. Muy interesante, pero creo que dejas a InDesign injustamente mal. Sí que es cierto que hay que corregir bastante cosa (las detalles del cual explico en un reciente post en mi blog, y también en mi libro sobre EPUB) pero no creo que el tema de las cursivas sea decisivo.

    Más importante aún es el formato original del archivo... si ya existe en InDesign, evidentemente es mucho más fácil convertirlo a EPUB desde InDesign.

    Y luego con GREP se soluciona todo :) al menos hasta que tengamos unas herramientas realmente potentes.

    Por último, me alegro mucho que hayan otros obsesionados con el código. Si va a funcionar esto, tenemos que cuidar la calidad mucho, pero mucho más.

    ResponderEliminar
  4. Completamente de acuerdo con Jaume. Los procesos automatizados (desde plugins de OpenOffice, Sigil y Calibre a InDesign) dejan mucho que desear y resulta mucho más rentable en el plano temporal meterse directamente en el código. Resultado: ePubs de mayor calidad... seguro.

    ResponderEliminar
  5. Jordi, "el malvado Mobi" (de Mobipocket, no de Amazon, que simplemente compró a la anterior y el formato es el mismo ya que lo único nuevo que ha añadido Amazon ha sido el DRM propio, cosa que no afecta a lo que estamos hablando), no sólo soporta esas "chorraditas" (llamar chorraditas a un estándar de anotado) sino que soporta el modelo XML DOM, que el ePub, hasta donde yo sé, sólo sueña.

    Y herramientas para genera Mobi las hay a espuertas: cualquier editor HTML y/o XHTML vale. Luego usas el Mobipocket Creator para convertir ese HTML a mobi, y si quieres con DRM, y encima gratis de trinca y legal, no como el DRM del ePub, que o bien pagas a Adobe la pasta gansa que valeo bien te creas el tuyo propio...

    ResponderEliminar
  6. Rfog: no me refería al anotado o al soporte de diccionarios como "chorraditas". Hablaba del punto 3, donde Jaume pone el ejemplo de las versalitas, que no están soportadas de forma nativa en ePUB.
    Hay herramientas de edición que soportan ePUB de forma nativa (con mayor o menor fortuna, sí) porque se trata de un estándar abierto y documentado. Sin embargo, el estándar MOBI, que es cerrado, no está documentado, por lo que no se sabe de antemano si, por ejemplo, soportará las versalitas.
    Resumiendo: un estándar abierto mola porque sabes cómo se va a comportar, al estar todo especificado en la definición, pero no mola porque son lentísimos para ponerse al día. Un estándar cerrado mola porque la empresa que lo mantiene va a ponerle todo lo que quiera sin retrasos burocráticos, pero no mola porque lo controla una única empresa que no suele compartir información sobre su funcionamiento.
    Y sí, sé que el MOBI fue desarrollado por Mobipocket, pero entiendo que al comprar Amazon a Mobipocket, se puede hablar del "malvado MOBI de Amazon". Por cierto, que yo no tengo nada en contra de Amazon, que para eso tengo un Kindle 3 y les compro libros y ebooks. Lo de "malvado" es una coña porque se suele poner a parir a Amazon por no bajarse del burro y dejarse asimilar por el borganismo ePUB + DRM de Adobe.

    ResponderEliminar
  7. Un matiz: mobipocket es tan abierto como ePub. Está igualmente basado en XHTML y es perfectamente editable sin DRM mediante

    ResponderEliminar
  8. Juan Luis: Que un estándar sea abierto no significa que se pueda editar (es decir, que no tenga formato binario), o que esté basado en otro estándar que sí es abierto.
    Significa que no se cobren licencias por usarlo (incluso de forma comercial), que esté bien documentado, que el proceso de diseño y mantenimiento del estándar sea público, que cualquiera con la calificación necesaria tenga la posibilidad de acceder al comité técnico del estándar, e incluso que cualquiera con la calificación técnica necesaria pueda hacer comentarios y sugerencias. Te pongas como te pongas, un estándar diseñado y controlado por una única empresa no puede ser abierto.
    De todas formas, hay mucha discusión al respecto. En la Wiki tienes un artículo MUY extenso al respecto: "open standard".

    ResponderEliminar
  9. Jordi, ya que estamos: un estándar es un formato que no sólo es abierto sino que está aceptado por una organización que define estándares (ECMA, ISO, OASIS, etc.). De momento hablamos de formatos, no de estándares.

    Después, eso de que "un estándar diseñado y controlado por una única empresa no puede ser abierto" tiene un contraejemplo y se llama PDF.

    Es un claro problema de lenguaje: yo me centraba en la parte de operación y tú en la de licencia. Sea como fuere, hasta que iDPF se decida a completar ePUB, de momento la discusión tiene un sentido relativo, porque es comparar un formato de ebook completo (mobipocket) contra uno que no lo es (epub)

    Te recomiendo, si me lo permites, la serie de post al alimón entre RFOG y yo. Busca epub vs. mobipocket, porque dedicamos un tiempo a desmenuzar la cuestión

    ResponderEliminar
  10. La ISO y demás organismos similares no necesariamente definen ni desarrollan estándares, pero sí los certifican. OASIS, por ejemplo, desarrolla y certifica sus estándares.

    Como ya dije, hay muchas definiciones de estándar abierto.
    Los casos del PDF y el Office Open XML son curiosos. Son estándares aprobados (que no desarrollados) por la ISO, pero para mí no son abiertos.

    MOBI no es un estándar aprobado por ninguna organización independiente, pero sí es un estándar en la medida en que su uso está muy extendido (en volumen de negocio, no en adopción). Al igual que los formatos de documentos binarios de Office 97-2003, que también eran estándares de facto.

    Dicho lo cual, tienes razón, es más importante remarcar aquí las carencias de ePUB como estándar de officio frente a las ventajas de MOBI como estándar de facto.

    ResponderEliminar
  11. Matiz: una organización como ISO o ECMA define un formato como estándar de acuerdo a ciertos procedimientos de definición. Hasta ese momento, no es estándar. De momento, ni ePUB ni MOBI son estándares. En tanto que iniciativas privadas, ninguno lo tiene asegurado para convertirse en estándar... sobre todo, cuando no es evidente su necesidad más allá del empaquetado de documentos XHTML

    ResponderEliminar
  12. Anónimo2:09 a. m.

    De LaTeX, ni hablamos.

    Saludos,

    ResponderEliminar
  13. bueno, bueno... en contra del .mobi diré (no es su culpa, del todo...) que, justamente por un proyecto que estoy llevando a cabo, hoy en día no hay lectores-e decentes (y a un precio decente) que soporten el DRM de mobipocket. Por lo que he visto ni el Kindle lo hace. Así que esa ventaja (que para mi sería una grandíssima ventaja no tener que instalar un Adobe Content Manager y la infraestructura que se necesita para mantenerlo), se queda en nada. Y deja un poco mal al resto de ventajas para según que proyectos...

    ResponderEliminar
  14. Cómo me hierve la sangre con tantá palabrería vana e inútil. El formato mobipocket lleva una espuerta de años especificado AQUÍ: http://www.mobipocket.com/dev/article.asp?BaseFolder=prcgen&File=mobiformat.htm

    ResponderEliminar
  15. RFOG, así es, pero la verdad es que cada vez menos lectores-e leen su DRM, y eso es una desventaja comercial inmensa...

    ResponderEliminar
  16. RFOG: Lamento haber dicho que MOBI no está documentado sin haberme, valga la redundancia, documentado. La verdad es que cuando hablo de la documentación de un estándar, pienso más bien en algo así: http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html, pero veo que la documentación de MOBI también es perfectamente válida. Retiro lo dicho y pido disculpas.

    Por otra parte, si te hierve la sangre por una chorrada así, yo de ti vigilaría las úlceras, que son mu malas.

    ResponderEliminar
  17. one more time: ni mobi ni epub son estándares, a D*s gracias en ambos casos

    ResponderEliminar
  18. Tú y yo tenemos distinta definición de "estándar", nada más.

    ResponderEliminar

Related Posts Plugin for WordPress, Blogger...