- 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
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”
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
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
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/)
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 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...
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
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
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
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:-PPersonalmente, 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
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
Adobe Digital Editions y RMSDK fueron vendidos recientemente a Wipro Engineering: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...
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