2 puntos por GN⁺ 1 일 전 | 1 comentarios | Compartir por WhatsApp
  • Incluso un EPUB sin DRM que pasa la validación puede ser tratado como “corrupted” en Kobo, y el problema no proviene de un error de formato del archivo sino de la compatibilidad con el motor de renderizado
  • epubcheck es la herramienta de validación estándar de facto para comprobar la estructura de un EPUB y el cumplimiento de sus reglas, pero no detecta problemas del parser de CSS anticuado de renderizadores específicos
  • Kobo usa RMSDK, el motor propietario de renderizado de ebooks de Adobe, que fue creado sobre EPUB2 y luego actualizado ligeramente para EPUB3, pero sin modernizarse
  • La causa del problema era una sola línea: max-width: min(150px, 30vw);, y ese código válido de CSS level 4 no es compatible con RMSDK, lo que hace que el libro no cargue en Adobe Digital Editions y Kobo
  • Para comprobar la compatibilidad con Kobo, epubcheck por sí solo no basta; hace falta una validación adicional abriendo realmente el archivo en Adobe Digital Editions

El problema empezó con un EPUB que pasaba epubcheck

  • Las herramientas de Adobe suelen usarse porque Creative Suite es un estándar de la industria o porque hay pocas alternativas, y la inquietud de este texto parte de la frustración con el software de Adobe
  • El nuevo libro se distribuyó como un archivo EPUB sin DRM entregado directamente a los lectores, y antes de publicarlo pasó por varios procesos y superó la revisión de epubcheck
  • epubcheck es la herramienta estándar de facto para verificar un ebook bien armado, y para aprobar la validación el manifest debe reflejar sin omisiones los fragmentos e imágenes dentro del libro
  • Si el orden de los elementos HTML no coincide o si se desvía aunque sea un poco de las reglas del International Digital Publishing Forum, la validación falla
  • Lograr que epubcheck pase al 100% no es fácil para principiantes, pero para quienes trabajan en publicación cumple un rol parecido al de un linter de tipos o una suite formal de pruebas
  • La expectativa natural es que un libro que pasa epubcheck funcione en cualquier lector o app compatible con EPUB

Solo en Kobo aparecía “corrupted”

  • El nuevo libro pasó epubcheck ruleset 3.3, pero un lector reportó que aparecía el mensaje “corrupted”
  • Para comprobar una posible compatibilidad hacia atrás también se ofreció una versión EPUB2, pero ese archivo, aunque cumplía completamente las reglas, daba el mismo problema
  • Ese lector comentó que el libro no se abría en varias generaciones de dispositivos Kobo
  • El mismo EPUB funcionaba sin problemas en otros entornos como Amazon Kindle, Apple Books y Thorium
  • La investigación mostró que Kobo usa RMSDK, el motor propietario de renderizado de ebooks de Adobe

La causa se redujo a RMSDK y Adobe Digital Editions

  • RMSDK es el motor central de Adobe Digital Editions y también se usa en varios dispositivos Kobo y en equipos antiguos de Sony y Nook
  • Este motor fue construido alrededor de 2010 con foco en EPUB2, y luego recibió una actualización ligera para EPUB3, pero nunca se modernizó
  • Saber que Kobo usa RMSDK no resolvió de inmediato la discrepancia entre epubcheck y el resultado en Kobo, pero sí dio una dirección clara para depurar
  • Al cargar el libro en Adobe Digital Editions, tal como se sospechaba, falló al abrirse y ni siquiera mostró un mensaje de error
  • Al intentar volver a cargarlo, aparecía un aviso de que el libro ya había sido agregado y no podía importarse de nuevo, pero la pantalla seguía en blanco
  • Después se probaron múltiples archivos derivados, y todas las variantes seguían pasando epubcheck
    • Se intentó reorganizar la estructura de carpetas, quitar metadatos, eliminar el atributo de idioma, generar un UUID nuevo, aplanar directorios, cambiar extensiones, recrear el ZIP y modificar el manifest
    • Aun con todos esos intentos, Adobe Digital Editions seguía fallando al cargar

La causa real: una línea de CSS válida

  • Al desactivar la hoja de estilos, el libro cargó de repente, lo que redujo el problema al ámbito de la hoja de estilos
  • Tras crear más variantes aplicando solo partes de la hoja de estilos, se identificó la línea exacta que causaba el fallo
.copyright img {
    max-width: min(150px, 30vw);
}
  • Ese código es completamente válido como CSS level 4, pero RMSDK no puede manejarlo
  • Al cambiarlo por la forma más antigua max-width: 150px;, el libro se abrió normalmente en Adobe Digital Editions
  • El parser de CSS de RMSDK parece haberse quedado más o menos en el estado de 2013 y no soporta flexbox, grid, funciones matemáticas ni propiedades personalizadas
  • Cuando encuentra CSS que no reconoce, no hace fallback ni muestra un error claro: simplemente falla en silencio
  • epubcheck realiza una verificación básica de CSS, pero por naturaleza no puede validar CSS pensando en renderizadores específicos que están rotos de base

La lección sobre validar compatibilidad con Kobo

  • Incluso en 2026, como Kobo sigue usando RMSDK como base para renderizar libros, una sola línea de CSS válida puede convertir un EPUB totalmente válido en un “corrupted file” completo
  • En este caso, Kobo no puede abrir el libro entero y tampoco ofrece un mensaje de error claro ni fallback
  • Para evitar el problema se distribuyó una nueva versión, con medidas para que los lectores no vuelvan a encontrarse con el mismo error
  • En un entorno ideal, RMSDK debería salir de su estado obsoleto respecto a CSS o al menos ofrecer manejo de errores, pero por ahora el problema sigue igual
  • Si quieres asegurarte de la compatibilidad con Kobo, epubcheck no basta: también hay que comprobar si realmente carga en Adobe Digital Editions
  • EPUB es un excelente estándar abierto para ebooks, pero muchas implementaciones revelan fallas estructurales profundas dentro de un ecosistema que prioriza las restricciones de acceso

1 comentarios

 
GN⁺ 1 일 전
Comentarios de Hacker News
  • Adobe siempre fue así. Tiró por la borda la enorme cuota de mercado de Flash, y la alternativa era algo tan simple como gastar unos cuantos millones de dólares en QA; al final logró que todos los fabricantes de navegadores coincidieran en que “es mejor que la web siga sin un socio tan poco confiable como este”
    Hace tiempo lancé algunas cosas con Flash, pero era un software horrible, lleno de heisenbugs: fallas aleatorias y cambios en un área que rompían funciones no relacionadas de otros módulos. Costaba como 800 dólares y el soporte era prácticamente inexistente; reporté varios bugs fáciles de reproducir, incluso con casos de prueba reducidos, pero después del siguiente lanzamiento solo recibí una respuesta automática diciendo que “tal vez ya se corrigió, así que compra una licencia a precio completo y compruébalo”

    • Te caiga bien o mal Steve Jobs, su decisión de no dar soporte a Flash en el iPhone y empujar HTML5 aceleró muchísimo la caída de Flash
    • Flash era mejor cuando se llamaba VideoWorks ;)
      También existía MusicWorks, y ambos eran solo para Mac en una etapa muy temprana. Con solo contar esto ya se nota la edad
    • Flash sigue sin tener rival como el medio de publicación más sencillo
      La estructura en capas de los sistemas de build de JavaScript y los “estándares web” son muchísimo más difíciles que simplemente dibujar algo, escribir unas funciones simples y generar un archivo estático que puedas incrustar o descargar en cualquier parte. Si quieres usar una alternativa a Flash, terminas gastando demasiado tiempo en configuración, y esos “estándares” además son peores
      No me gusta Steve Jobs por matar Flash, ni Adobe por haber administrado tan mal una de las tecnologías más increíbles de la web. Los niños que crecen hoy no saben lo mágico que era Flash. Era como una especie de Roblox o Minecraft para la web
      Los sitios web todavía son peores que el Flash de principios de los 2000. Han pasado décadas y apenas imitan una parte de su poder, sin acercarse en nada a su facilidad
  • Durante bastante tiempo intenté crear software para lectores de libros electrónicos, y al final traté de hacer un pacto con el diablo y montarme sobre RMSDK
    Pero no hay forma de acceder. No es solo que la licencia sea demasiado cara para un desarrollador independiente, que claro, también lo es, sino que literalmente no hay con quién hablar. El correo que aparece en el sitio web no responde en absoluto, ni siquiera con un “gracias por tu interés” o “te contactaremos de nuevo”
    Le pregunté a un excolega que había trabajado ahí sobre el proceso para obtener acceso a RMSDK; buscó documentos internos pero no encontró nada. También busqué en LinkedIn gente que parecía estar relacionada con RMSDK y pasó exactamente lo mismo
    Mientras tanto, las editoriales distribuyen la mayoría de sus libros solo a través de uno de los proveedores de DRM conocidos, como Apple, Amazon o Adobe, y los dos primeros son completamente cerrados. Si esto no es una práctica monopólica anticompetitiva, no sé qué lo sea

    • He leído muchos libros con la app FBReader, y publican un SDK para usarlo en otras aplicaciones
  • Hasta donde sé, los dispositivos Kobo usan un motor de renderizado más avanzado si el archivo se llama .kepub.epub. Parece estar basado en ePub 3, aunque no sé si eso corregirá el problema de aquí
    En lo personal, antes de pasar un ePub a Kobo lo convierto con kepubify(https://pgaskin.net/kepubify/try/)

    • Sí, yo también hago eso con todos mis archivos. Editoriales como Standard Ebooks también ofrecen descargas en kepub, y como se explica aquí, el lector de Adobe también tiene problemas
      https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...
      Me encanta la Kobo Clara Colour, y creo que sería perfecta si tan solo quitaran el lector de Adobe. También probé KOReader, pero me gustan los libros de biblioteca de OverDrive y la Kobo Store, así que no me cambié por completo
  • Por desgracia, epub y epubcheck no son ese criterio excelente e incuestionable que menciona el autor. Cuando W3C, Inc. se hizo cargo del mantenimiento de la especificación alrededor de ePub 3.1, simplemente empezó a referenciar WHATWG HTML y las especificaciones de navegadores cada vez más grandes([1])
    Esos “estándares vivos” no tienen versionado ni QA. Como resultado, al basarse en una versión de HTML que redefinió los encabezados y el seccionamiento, ePub 3.2 terminó volviendo no conformes a ePub anteriores. Por eso Calibre y otras herramientas todavía recomiendan 3.1, o mejor aún, 2
    El caso en que se rechaza la función CSS min() también muestra que traer completa una especificación de CSS excesivamente compleja no ayuda mucho. Los lectores de libros electrónicos no son navegadores que se actualicen siempre a la última versión
    [1]: https://news.ycombinator.com/item?id=41326179

    • En el mundo de ePub es bien sabido que apuntar a 3.1 o 2 suele ser una decisión más sensata
      En los problemas de compatibilidad de EPUB, siempre hay que sospechar primero del CSS. Usar funciones “modernas” de CSS y luego quejarse de que no hay flexbox ni grid es pensar como desarrollador web
      Que EPUB comparta parte del stack con la web no significa que ambos se superpongan por completo, ni que deban hacerlo. La mayoría de los lectores dedicados con tinta electrónica no usan un navegador para renderizar; incorporan en el firmware una cadena de herramientas de análisis y renderizado HTML/CSS hecha para ese propósito, y la actualizan muy de vez en cuando. Si te interesa, puedes ver crengine de KOReader o Crosspoint reader, que corre en ESP32
      La entrada del blog huele demasiado a estilo de escritura de IA excesivamente confiado, pero no hay que dejarse engañar
  • Si alguien está buscando un dispositivo, también está PineNote
    https://pine64.org/devices/pinenote/
    Es más caro y tiene menos software listo para usarse, pero es mucho más directo y con menos restricciones en cuanto a la propiedad del dispositivo y qué software se puede ejecutar en él
    También hay textos que resumen bien la experiencia de usar PineNote
    https://shom.dev/posts/20250308_pinenote-day-one/
    https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...

    • Me pregunto si alguien aquí lo ha usado directamente. Cuesta 400 dólares y dice que está “dirigido a desarrolladores de Linux con mucho conocimiento de sistemas embebidos o experiencia con Linux móvil”. El firmware comunitario enlazado tampoco se ha actualizado en más de un año
      Kobo tampoco limita lo que se puede hacer. Se puede hacer sideload de software alternativo de lectura de ebooks, como KOReader, para mejorar las funciones del lector integrado
    • También vale la pena echarle un vistazo a la pantalla e-ink open source de 60Hz de esta persona: [video] https://www.youtube.com/watch?v=nHbA2-_qzH4
  • Kobo de hecho está reescribiendo por completo su software lector de ebooks, y en la UE ya se puede descargar una beta. Casi seguro que ya no está basado en RMSDK
    Adobe fue deficiente como administrador y luego, al venderlo a un tercero que también arruinó la migración y terminó molestando aún más a usuarios finales y plataformas, prácticamente le sirvió en bandeja de plata el mercado del DRM para EPUB a LCP. Las plataformas se están alejando de Adobe más rápido que nunca

    • Me pregunto si alguien ya probó la beta. Me gustaría saber si realmente mejoró bastante
  • La parte que dice “temía ese momento de presionar el botón de validación en un libro terminado después de meses de trabajo. Porque siempre encontraba algo de qué quejarse” me hizo pensar en estudiantes de maestría al borde del llanto intentando compilar un borrador de paper en LaTeX
    Se tomaron demasiado literalmente eso de “primero escribe y luego piensa en el formato”, así que estaban intentando compilar por primera vez justo antes de la fecha límite

    • Aun así, en conjunto probablemente sí les ahorró bastante tiempo. Solo por los tiempos de compilación, si hubieran estado iterando y revisando antes, quizá habrían desperdiciado mucho más tiempo
      Aunque no sé qué tanto influyó la fecha límite que se venía encima en esa percepción ;-P
  • Hay que darse por bien servido si el lector usa un lector ePub que siquiera soporte o al menos ignore algo como max-width :-P
    Personalmente, usando lectores ePub, a veces he tenido que arreglar a mano archivos que no funcionaban o se veían raro por estilos innecesarios. También he oído de archivos que del lado del autor no tenían problema, pero para otra persona eran imposibles de leer, y me da la impresión de que, salvo que de verdad se necesite un formato vistoso, es mejor quedarse con el HTML más básico posible, algo que ni IE4 renderice demasiado mal
    Por eso a veces pienso que algún día podría hacer una herramienta de reconstrucción de epub que recomponga un ePub usando el HTML/CSS más simple posible. Idealmente debería poder configurarse para máxima compatibilidad

    • Si HTML/CSS apenas funciona en el entorno objetivo de navegador web, no sé por qué alguien pensó que era buena idea usar esto para libros
      Muchas veces he pensado que estaría bien definir un subconjunto que funcione rápido en cualquier computadora y usar solo eso para las páginas web que hago. Si alguien definiera un alcance así para ePub, sería muchísimo más útil
    • Supongo que es como no pintar el centro de un dibujo porque los lentes de alguien podrían estar rotos y hacer que se vea raro. O tal vez habría que exigirles a los fabricantes de lentes que hagan lentes mejores, y dejar que los artistas hagan su arte
  • Adobe Digital Editions y RMSDK fueron vendidos recientemente a Wipro Engineering: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...

    • Me pregunto si fue una venta de verdad o más bien outsourcing
  • Entiendo la frustración del autor, pero ¿cuántos lectores habrá usando lectores ePub viejos, no actualizados o imposibles de actualizar? Si un autor quiere que su obra llegue a todos sus lectores, tiene que ajustarse al mínimo común denominador
    Si eso termina siendo algo de 2013, pues qué pena, pero esa es la realidad del mercado

    • Yo lo leí como que los Kobo nuevos que salgan en 2026 usarán software de DRM de Adobe con reglas CSS congeladas en 2013