Me interesa mucho la intersección entre los ebooks, la seguridad y la web LowJS, así que este tema me parece importante.
Hace falta un formato de ebook portable en un solo archivo, pero PDF no es la respuesta porque no permite redistribuir el texto.
HTML+CSS en 2024 puede reproducir casi cualquier medio impreso y, al mismo tiempo, permitir que el texto se redistribuya.
No creo que JavaScript deba ser obligatorio. Un ebook debe ser un libro cuyo tamaño pueda cambiarse de forma significativa, y sus funciones básicas como libro deben funcionar aunque JavaScript esté desactivado. Si se necesitan interacciones o mejoras, se puede usar JavaScript, pero si sin JavaScript no funciona como libro, lo considero un bug.
Creo que poner todos los estilos inline es un error, porque puede romper la CSP de algunos usuarios. Los estilos deberían separarse como recursos con rutas relativas al HTML, y el ebook debería prohibir cargar recursos de otros dominios.
Por último, basta con distribuirlo como un archivo zip. Me parece que los ebooks ya funcionan así, ¿no?
Eso de que “los ebooks ya funcionan como zip” es cierto hasta cierto punto. Las herramientas de unzip pueden descomprimir archivos EPUB y, si hace falta, se les puede cambiar la extensión de .epub a .zip.
Pero en la dirección contraria no siempre se cumple. Aunque el mismo conjunto de archivos haya sido un EPUB válido antes de descomprimirlo, si lo vuelves a empaquetar en zip de cualquier manera puede dejar de ser un EPUB válido.
Dentro del zip de EPUB, el archivo mimetype es especial: debe ser el primer elemento del archivo, su contenido debe ser únicamente application/epub+zip y debe almacenarse sin compresión.
Sorprendentemente, muchas herramientas zip hacen que esto sea molesto porque cambian el orden de los archivos o dificultan guardar solo algunos archivos sin comprimir. Los programas zip de línea de comandos normalmente lo permiten con flags, pero en bibliotecas zip puede ser bastante doloroso. Lo digo por experiencia desarrollando software para generar EPUB.
Es importante distinguir entre un archivo zip común y un ebook. Para eso se puede usar la extensión .epub.
Lo que describes es el formato ePub, donde archivos HTML, CSS e imágenes van dentro de un archivo zip.
Me pregunto qué tal sería un ZIP autoextraíble. Por ejemplo, como esta página: https://gildas-lormeau.github.io/
También incluye una CSP para hacerlo seguro.
No me gusta mucho la idea de empaquetar todo en zip.
Una ventaja que tenían los antiguos archivos .doc frente a .docx era que, en una carpeta con cientos o miles de archivos, se podía buscar una palabra específica muy rápido. Con el formato zip eso no se puede.
Acabo de guardar algo como .doc y abrirlo con un editor hexadecimal, y el contenido real estaba en texto plano. Los formatos zip o los archivos PDF son difíciles de buscar con grep, y también dudo de que la compresión sea realmente necesaria para textos de unos pocos miles de caracteres.
Si hablamos de que “HTML+CSS en 2024 puede reproducir casi cualquier medio impreso”, esto también vale la pena verlo: https://www.princexml.com/samples/
Es un artículo muy bien armado, escrito por el desarrollador de Nota, que busca llevar el formato EPUB a un nivel equivalente al de PDF. Ya creó un visor, y el propio artículo se muestra mediante un puerto WASM de ese visor basado en navegador.
Uno de los problemas es hasta qué punto EPUB, que en la práctica es XHTML, puede reproducir un layout con precisión. El criterio del artículo original es que el documento se vea “razonablemente bien”, pero para estar a la altura de PDF parece insinuar que HTML necesitaría nuevas funciones de layout, al menos en lo relacionado con los saltos de línea.
Veo dos formas de avanzar. Una es que los navegadores ofrezcan más herramientas tipográficas; se dice que text-wrap: pretty ayuda, pero en una prueba rápida no me pareció que mejorara la calidad de los saltos de línea. La otra es precalcular los saltos de línea, pero eso solo es posible en renderizados de layout fijo.
Además, aunque el autor menciona las notas, no me queda claro cómo piensa implementarlas.
El autor también trata los EPUB de layout fijo. EPUB puede especificar paginación básica, saltos de línea, fuentes, tamaño de fuente, tamaño de página, posición de imágenes, etc., para que se renderice igual en todas partes.
Esto ya es posible en EPUB3, pero tiene la desventaja de que no se ve bien en pantallas como las de los teléfonos. Según el lector, se pueden sobrescribir los valores por defecto, pero entonces hay que esperar que el lector rehaga el documento para que se vea bien.
Una alternativa es que el EPUB especifique varios renderizados para tipos de pantalla comunes. No es perfecto, pero parece un buen punto medio: que el creador del documento proporcione valores por defecto y que el usuario pueda sobrescribirlos si quiere.
PDF no tiene función de redistribución de texto. Se parece más a un formato de dibujo, similar a SVG, y es más rígido, así que cosas como el reflow de texto no funcionan.
Lo que necesita un formato de ebook es marcado semántico que se adapte al dispositivo donde se renderiza. HTML+CSS se creó originalmente para ese propósito.
Por lo tanto, quien diseña el layout de un libro debe ceder conscientemente al lector parte del control sobre cómo se verá. Un poco de imperfección visual es un precio razonable a pagar. Si se necesita perfección visual, se puede usar PDF.
Claro que la cosa se complica cuando hay elementos interactivos. Para los elementos interactivos grandes, sería mejor abrirlos en una vista dedicada cuando haga falta; para los pequeños, convendría aceptar el reflow.
Creo que CSS básicamente sí soporta funciones de layout para medios paginados. ¿No bastaría con que el lector EPUB implementara un modo de visualización tradicional de “vista previa de impresión”?
Irónicamente, el propio ejemplo de notas que da el autor no funciona bien en mi entorno. En Firefox para Android con pantalla táctil, al mantener presionado aparece un enlace en lugar de un pop-up.
Creo que las notas y referencias ya están incluidas en la especificación EPUB, y quizá incluso en la especificación HTML.
Tampoco estoy de acuerdo en que mantener presionado para abrir un pop-up sea mejor que un ancla de hipervínculo común. Si la función de “volver” del lector funciona correctamente, o si las referencias bidireccionales tienen un enlace de “atrás”, navegar de un punto a otro resulta mucho menos intrusivo.
Antes existía algo llamado XSL Formatting Objects(XSL-FO). Apuntaba a algo parecido a un PDF basado en XML, pero de más alto nivel, por lo que también permitía redistribuir texto.
La idea era distribuir juntos un documento XML y una hoja de estilos XSL, transformarlos en FO para el renderizado y poder tener varias hojas de estilos para el mismo documento según el dispositivo de destino o el tamaño de página.
En Firefox uso el add-on SinglePage para guardar el DOM de la página actual como un archivo HTML autónomo. Inserta en línea el CSS y las URL data: para las imágenes, y elimina dependencias y scripts.
No es perfecto y no confío en que los navegadores siempre mantengan compatibilidad hacia atrás, pero lo prefiero antes que guardar una página como PDF o como varios archivos.
Curiosamente, una de las pocas páginas en las que falló este add-on fue justamente este artículo sobre EPUB portátiles. Parece que tiene demasiada magia para ajustar el formato. La página guardada se puede leer, pero el estilo no se parecía en nada al original.
Me gusta que fbreader en Android muestre todos los libros igual, según la configuración de la app, en vez de usar los estilos del archivo EPUB. Nunca lo he visto aplicar CSS ni intentar ejecutar scripts incluidos en el archivo, y espero que nunca lo haga. Cargar dependencias externas sería una idea aún peor, y ni siquiera sabía que eso estuviera permitido.
Creo que te refieres a SingleFile.
Ya que hablamos de eso, el sistema de permisos de los add-ons de Firefox es raro. Para hacer algo interesante casi siempre terminas pidiendo permisos para todo, y eso crea un mercado natural de add-ons que actores maliciosos pueden salir a comprar para tomar el control.
Por ejemplo, el add-on SingleFile sí necesita permisos de acceso, porque tiene que inspeccionar el DOM renderizado y guardarlo como archivo. Pero me pregunto por qué tiene que acceder a todo. ¿No se podrían conceder permisos como snapshot DOM once o write to a single file?
Creo que uno de mis primeros comentarios en HN, hace unos 10 años, fue sobre querer guardar páginas web HTML como HTML, no como PDF.
En ese momento probablemente no pude explicar ni entender bien por qué, pero lo trataron como un deseo absurdo. Me alegra ver ahora que quizá simplemente estaba desfasado unos 10 años con la época.
Otro comentario explica bien por qué esta página es difícil de parsear. Es un artículo de la persona que desarrolla Nota intentando llevar EPUB al mismo nivel que PDF, y el propio artículo se muestra en un visor basado en navegador y WASM.
FBReader usa por defecto el CSS del documento. Si no recuerdo mal, se puede desactivar en unos cuatro pasos.
KOReader es menos amigable, pero ofrece más control. Puedes elegir entre varios archivos CSS incluidos o incluso escribir el tuyo.
Entre las ventajas de KOReader también están su excelente soporte para OPDS y un servidor de sincronización autoalojado fácil de usar.
Este artículo tiene un botón para descargar el EPUB.
Con esa función, en las páginas que usan este sistema ya no hace falta SinglePage.
Al ver esa parte volví a fijarme. Es la parte que dice: “Por eso decidí crear Bene, un sistema de lectura de EPUB más ligero. Es lo que están usando ahora. Este documento es un EPUB y se puede descargar con el botón de la esquina superior derecha”.
Al leerlo en un navegador de escritorio, no me di cuenta en absoluto hasta que me lo señalaron directamente. En móvil, el encabezado ocupa más pantalla y se nota más, pero fuera de eso se comporta casi como una página web normal.
Probablemente sea una buena señal.
A diferencia de lo que dijeron algunos comentarios, no vi —o al menos no noté— ningún spinner al cargar el documento por primera vez. En el teléfono sí apareció, pero pasó bastante rápido. No sé si eso era la carga del programa WASM o si solo ocurre en la primera carga.
Lo que el spinner espera principalmente es la descarga del archivo .epub. Ese archivo pesa 4.77 MB, así que es bastante grande si no tienes una conexión rápida. Después de descomprimirlo, la mayor parte del tamaño la ocupan las imágenes, como el 99%.
A diferencia de una página web normal o un PDF, parece que no empieza a renderizar hasta que se descargan todos los recursos, es decir, todo el ePub.
Una diferencia que pensé que el artículo trataría, pero no trató, es el rendimiento. Los PDF pueden optimizarse para que las páginas sean bastante independientes, lo que permite renderizado progresivo, acceso aleatorio y alta paralelización.
En el teléfono no me di cuenta en absoluto hasta leer el artículo. Pensé que era simplemente una página web normal que explicaba el proyecto.
Incluso solo por el hecho de que los navegadores no puedan abrir EPUB, se siente como un proyecto un tanto condenado al fracaso. Si enlazas un PDF, aunque haya un pequeño cambio de contexto, el navegador lo abre y lo muestra.
Según la descripción, EPUB es básicamente HTML, así que es raro que el navegador no lo abra, pero no parece fácil convencer a los burócratas de Chrome/Mozilla.
Otro punto desalentador es que HTML y CSS se volvieron tan enormes e inflados que casi no hay gente capaz de implementar un “lector” para EPUB/HTML. En la práctica se vuelve “implementa un navegador nuevo”. A largo plazo parece más viable algo como Djot, un Markdown fácil de parsear con un poco de capacidad de renderizado encima.
Mi solución provisional personal es meter CSS, SVG, scripts e incluso imágenes base64 en un solo archivo HTML. Es parecido a EPUB, algo inflado y feo, pero con un poco de cuidado funciona y el navegador puede abrirlo de forma natural.
Sin embargo, el usuario no tiene forma de saber que “puede descargar esta página web y guardarla offline”. Sería bueno tener una extensión como .htmls que indique que es un HTML sin recursos externos.
Hasta hace no mucho, los navegadores tampoco podían abrir PDF. Ahora todos los navegadores incluyen un lector de PDF escrito en ASM/JS.
No parece haber razón para que los navegadores no puedan hacer lo mismo con EPUB. Ya existen extensiones de navegador que hacen exactamente eso. El problema es si el formato EPUB gana popularidad.
HTML originalmente era hipertexto. Unos cuantos enlaces, dibujos/imágenes y tablas.
Luego se “necesitaron” diseños y layouts tipo revista, pero seguía siendo bastante decente porque todavía estaba basado en documentos.
Después se intentó encajar HTML a la fuerza como plataforma de distribución de aplicaciones. El layout CSS actual por fin se acercó más a los motores de layout tradicionales de aplicaciones.
Creo que los últimos 20 años se desperdiciaron en gran medida por no tener una forma adecuada de distribuir aplicaciones multiplataforma. Salvo Java.
Entonces parece que este artículo en sí es un EPUB abierto con un visor EPUB en WASM.
El mayor obstáculo se siente como el alcance de implementación de HTML/CSS. El autor dice: “Principio de generación de HTML portable: cuando sea posible, un sistema que genere EPUB portables debe producir HTML portable”, pero no parece haber ido lo suficientemente lejos.
Para que este formato funcione de manera repetible en todas partes, debe estandarizarse y también debe ser fácil implementar nuevos motores de renderizado. Depender de webviews no se siente como el camino a seguir.
La belleza de PDF está en que es muy confiable. Un PDF de hace 10 años se renderiza hoy exactamente igual que antes.
Para que este esfuerzo tenga éxito, creo que habría que reducir mucho el alcance del documento. El subconjunto permitido de XHTML debería ser muy limitado, y se debería priorizar la capacidad de renderizarse con el mismo aspecto en todas partes. Primero un layout fijo con tamaño de página fijo, y después documentos con reflow. También hace falta un estándar que incluya documentos de prueba exhaustivos y salidas de renderizado.
Aunque los navegadores no ofrecen una UI cómoda para abrir EPUB, no deberían tener problemas para renderizar los archivos HTML por capítulo que hay adentro.
Si no hay soporte del navegador, no sería tan difícil escribir un proxy del lado del servidor que convierta un EPUB en un sitio navegable, con controles para cambiar de capítulo y algunas opciones simples de layout.
Claro que el soporte de DRM necesario para ver la mayoría de los ebooks comerciales con ese proxy probablemente sería muy problemático legalmente.
Pensándolo bien, el soporte de EPUB con DRM aprobado por editoriales en el navegador está técnicamente a medio paso del soporte de DRM para páginas web normales, lo cual es una perspectiva bastante horrible.
Creo que PDF es un formato legacy terrible, con complejidad innecesaria. Como la mayoría de los usos de PDF no tienen que ver con impresión, la lógica de composición tipográfica tampoco me convence.
En la gran mayoría de los casos de uso, es mucho más importante que sea fácil de leer en teléfonos, tablets y computadoras.
Me sorprendió que el autor dijera que iBooks no soporta vista con desplazamiento, así que lo comprobé. iBooks en macOS no soporta desplazamiento para archivos ePub, pero sí lo soporta en iOS y iPadOS. Una decisión muy extraña de Apple. https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
La especificación de PDF es molesta, pero no hay absolutamente nada que la reemplace.
Nunca he visto documentación técnica distribuida en un formato que no sea PDF y que fuera cómoda de leer y buscar. Ni siquiera en el teléfono.
No quiero documentos cuya apariencia cambie según un estado transitorio como el dispositivo de lectura o el tamaño de la ventana. Quiero documentos con un layout fijo, bien diseñado por el autor.
Incluso al leer en una pantalla o ventana pequeña, si no es un documento de texto simple, quiero un lector inteligente con zoom y desplazamiento rápidos, no cambios de layout. No debería tener comportamientos tontos como algunos lectores de Android, donde el scroll vertical o Page Up/Page Down también mueven la posición horizontal y hacen difícil leer columnas de texto.
Con solo respetar las recomendaciones tradicionales de ancho máximo para columnas de texto, alcanza para leer cómodamente en un teléfono. Leer en el teléfono solo se vuelve incómodo cuando el autor crea columnas demasiado anchas y rompe las reglas tradicionales de tipografía.
La razón para querer documentos de layout fijo no es solo la impresión. Es porque fijar el layout del documento es más importante que adaptarse a pantallas pequeñas.
No conozco bien este caso en particular, pero algunos lectores pueden hacerlo así por consistencia con los dispositivos de tinta electrónica. En la tinta electrónica, el scroll está limitado por hardware debido a la baja tasa de refresco, procesadores débiles y ahorro de batería.
Por eso creo que es mala idea intentar crear un solo estándar que sirva para todo. Sería mejor tener dos estándares de documentos digitales. Uno con capacidades completas de multimedia e interacción, excepto networking; y otro como subconjunto de ese, en blanco y negro, sin multimedia, con interacción limitada principalmente a hipervínculos dentro del documento.
Y, de hecho, ya existen casi esos dos formatos. HTML, MHTML=EML y EPUB.
Por supuesto, también hace falta un tercer formato para conservación física y para los raros documentos digitales de layout fijo, y PDF/A ya parece cumplir bastante bien ese rol.
Si realmente hay que imprimir algo, PDF es la ruta más confiable y portable.
Quizás SVG multipágina también podría servir, pero para imprimir correctamente varias páginas parece que al final habría que exportar primero a PDF. Lo digo pensando en Inkscape.
Me pregunto qué ofrece un lector EPUB que no tenga un navegador. Por ahora, la respuesta parece ser una sola cosa, y menor: poder tratar un archivo .epub, es decir, un archivo zip, como un directorio
Si esa es realmente la única diferencia entre un lector EPUB y un subconjunto del navegador, la forma más simple y de menor esfuerzo sería esta:
hacer que los navegadores existentes traten los archivos zip como directorios bajo ciertas condiciones.
Definir una restricción de HTML verificable mecánicamente que garantice recursos completamente locales, como dice el artículo original. Podría bastar con exigir que todas las URL, salvo los enlaces, sean rutas relativas.
Declarar como “EPUB portátiles” los archivos zip que cumplan esta restricción.
Olvidarse por completo de los lectores EPUB dedicados, existentes o nuevos.
Estoy de acuerdo. Esto suena como la solución real
Para los recursos completamente locales, me gustaría ver el requisito de que todos los objetos tengan una opción de reemplazo disponible localmente. Por ejemplo, si no se puede obtener esa fuente, se usa una fuente estándar. Aunque no se vea perfecto, si se limita dentro del alcance de las alternativas debería funcionar razonablemente bien
Hay un modo de falla que todavía no se ha tratado lo suficiente: las imágenes que no funcionan bien. Fundamentalmente, las imágenes no se pueden refluir. En gran medida esto podría resolverse usando SVG, pero no cuando se trata de imágenes ráster reales. Al final, probablemente no quede otra que ofrecer varias resoluciones
También me encontré con un problema relacionado y todavía no he visto una buena respuesta: un SVG que sea consciente de la resolución y, cuando haya suficiente resolución disponible, traiga una imagen más detallada. Si dibujas líneas subpíxel se ven borrosas, pero al ampliar esa misma imagen esas líneas se vuelven útiles. Los íconos de Windows reconocen esto al poder incluir varias resoluciones y usar la adecuada según el contexto
El autor es investigador posdoctoral bajo la supervisión de Shriram Krishnamurthi. Shriram Krishnamurthi es autor de Programming Languages: Application and Interpretation(PLAI) y coautor de Data-Centric Introduction to Computing(DCIC)
Ahora estoy leyendo tanto PLAI como DCIC, y me impresiona mucho el cuidado minucioso que los autores pusieron para convertirlos en obras de arte educativas. Eso sí que es cariño https://willcrichton.net/
Los PDF pueden incluir fuentes, pero con frecuencia no lo hacen y dependen de las fuentes del sistema. Una razón es que meter las fuentes en el PDF puede aumentar mucho el tamaño del archivo. En algunos casos, una sola fuente puede ser más grande que el resto del archivo completo
Una vez implementé la incrustación de fuentes en software que generaba PDF, y fue sorprendentemente difícil descubrir cómo hacer que funcionara de forma confiable
Que los PDF se rendericen de manera consistente tampoco es tan cierto como uno podría pensar. Varias veces vi que el mismo PDF se renderizaba de forma distinta según el visor de PDF usado. Por lo general las diferencias son sutiles, pero a veces hay casos límite con diferencias bastante grandes. También me pasó que la misma versión de Acrobat Reader renderizara un PDF de forma distinta según el sistema operativo
Solo hay unas pocas fuentes estándar del sistema que se pueden omitir de un archivo PDF, y el documento asume que las fuentes usadas para el renderizado tienen las mismas métricas que tipografías tradicionales como Times, Helvetica o Courier
Por lo tanto, si se usan fuentes del sistema compatibles, el diseño del documento renderizado no debería cambiar. Claro que hay casos de fuentes del sistema que se promocionan como compatibles en métricas con las antiguas fuentes Adobe PostScript, pero tienen diferencias sutiles
Salvo por el pequeño conjunto de fuentes estándar del sistema, los documentos PDF normalmente incluyen solo el subconjunto de glifos correspondiente a los caracteres usados en el texto real, no la fuente completa
Durante más de 20 años pensé que los PDF se renderizaban de manera consistente, hasta que en una entrevista me dijeron que mi documento se veía raro y recién entonces me enteré de que podían faltar fuentes
Fue un The Daily WTF de la vida cotidiana
Me pregunto si existe software que minimice las fuentes eliminando los puntos de código que no se usan en el documento
1 comentarios
Opiniones de Hacker News
Me interesa mucho la intersección entre los ebooks, la seguridad y la web LowJS, así que este tema me parece importante.
Hace falta un formato de ebook portable en un solo archivo, pero PDF no es la respuesta porque no permite redistribuir el texto.
HTML+CSS en 2024 puede reproducir casi cualquier medio impreso y, al mismo tiempo, permitir que el texto se redistribuya.
No creo que JavaScript deba ser obligatorio. Un ebook debe ser un libro cuyo tamaño pueda cambiarse de forma significativa, y sus funciones básicas como libro deben funcionar aunque JavaScript esté desactivado. Si se necesitan interacciones o mejoras, se puede usar JavaScript, pero si sin JavaScript no funciona como libro, lo considero un bug.
Creo que poner todos los estilos inline es un error, porque puede romper la CSP de algunos usuarios. Los estilos deberían separarse como recursos con rutas relativas al HTML, y el ebook debería prohibir cargar recursos de otros dominios.
Por último, basta con distribuirlo como un archivo zip. Me parece que los ebooks ya funcionan así, ¿no?
Pero en la dirección contraria no siempre se cumple. Aunque el mismo conjunto de archivos haya sido un EPUB válido antes de descomprimirlo, si lo vuelves a empaquetar en zip de cualquier manera puede dejar de ser un EPUB válido.
Dentro del zip de EPUB, el archivo mimetype es especial: debe ser el primer elemento del archivo, su contenido debe ser únicamente
application/epub+zipy debe almacenarse sin compresión.Sorprendentemente, muchas herramientas zip hacen que esto sea molesto porque cambian el orden de los archivos o dificultan guardar solo algunos archivos sin comprimir. Los programas zip de línea de comandos normalmente lo permiten con flags, pero en bibliotecas zip puede ser bastante doloroso. Lo digo por experiencia desarrollando software para generar EPUB.
Lo que describes es el formato ePub, donde archivos HTML, CSS e imágenes van dentro de un archivo zip.
También incluye una CSP para hacerlo seguro.
Una ventaja que tenían los antiguos archivos .doc frente a .docx era que, en una carpeta con cientos o miles de archivos, se podía buscar una palabra específica muy rápido. Con el formato zip eso no se puede.
Acabo de guardar algo como .doc y abrirlo con un editor hexadecimal, y el contenido real estaba en texto plano. Los formatos zip o los archivos PDF son difíciles de buscar con grep, y también dudo de que la compresión sea realmente necesaria para textos de unos pocos miles de caracteres.
Es un artículo muy bien armado, escrito por el desarrollador de Nota, que busca llevar el formato EPUB a un nivel equivalente al de PDF. Ya creó un visor, y el propio artículo se muestra mediante un puerto WASM de ese visor basado en navegador.
Uno de los problemas es hasta qué punto EPUB, que en la práctica es XHTML, puede reproducir un layout con precisión. El criterio del artículo original es que el documento se vea “razonablemente bien”, pero para estar a la altura de PDF parece insinuar que HTML necesitaría nuevas funciones de layout, al menos en lo relacionado con los saltos de línea.
Veo dos formas de avanzar. Una es que los navegadores ofrezcan más herramientas tipográficas; se dice que
text-wrap: prettyayuda, pero en una prueba rápida no me pareció que mejorara la calidad de los saltos de línea. La otra es precalcular los saltos de línea, pero eso solo es posible en renderizados de layout fijo.Además, aunque el autor menciona las notas, no me queda claro cómo piensa implementarlas.
Esto ya es posible en EPUB3, pero tiene la desventaja de que no se ve bien en pantallas como las de los teléfonos. Según el lector, se pueden sobrescribir los valores por defecto, pero entonces hay que esperar que el lector rehaga el documento para que se vea bien.
Una alternativa es que el EPUB especifique varios renderizados para tipos de pantalla comunes. No es perfecto, pero parece un buen punto medio: que el creador del documento proporcione valores por defecto y que el usuario pueda sobrescribirlos si quiere.
Lo que necesita un formato de ebook es marcado semántico que se adapte al dispositivo donde se renderiza. HTML+CSS se creó originalmente para ese propósito.
Por lo tanto, quien diseña el layout de un libro debe ceder conscientemente al lector parte del control sobre cómo se verá. Un poco de imperfección visual es un precio razonable a pagar. Si se necesita perfección visual, se puede usar PDF.
Claro que la cosa se complica cuando hay elementos interactivos. Para los elementos interactivos grandes, sería mejor abrirlos en una vista dedicada cuando haga falta; para los pequeños, convendría aceptar el reflow.
Creo que las notas y referencias ya están incluidas en la especificación EPUB, y quizá incluso en la especificación HTML.
Tampoco estoy de acuerdo en que mantener presionado para abrir un pop-up sea mejor que un ancla de hipervínculo común. Si la función de “volver” del lector funciona correctamente, o si las referencias bidireccionales tienen un enlace de “atrás”, navegar de un punto a otro resulta mucho menos intrusivo.
La idea era distribuir juntos un documento XML y una hoja de estilos XSL, transformarlos en FO para el renderizado y poder tener varias hojas de estilos para el mismo documento según el dispositivo de destino o el tamaño de página.
En Firefox uso el add-on SinglePage para guardar el DOM de la página actual como un archivo HTML autónomo. Inserta en línea el CSS y las URL
data:para las imágenes, y elimina dependencias y scripts.No es perfecto y no confío en que los navegadores siempre mantengan compatibilidad hacia atrás, pero lo prefiero antes que guardar una página como PDF o como varios archivos.
Curiosamente, una de las pocas páginas en las que falló este add-on fue justamente este artículo sobre EPUB portátiles. Parece que tiene demasiada magia para ajustar el formato. La página guardada se puede leer, pero el estilo no se parecía en nada al original.
Me gusta que fbreader en Android muestre todos los libros igual, según la configuración de la app, en vez de usar los estilos del archivo EPUB. Nunca lo he visto aplicar CSS ni intentar ejecutar scripts incluidos en el archivo, y espero que nunca lo haga. Cargar dependencias externas sería una idea aún peor, y ni siquiera sabía que eso estuviera permitido.
Ya que hablamos de eso, el sistema de permisos de los add-ons de Firefox es raro. Para hacer algo interesante casi siempre terminas pidiendo permisos para todo, y eso crea un mercado natural de add-ons que actores maliciosos pueden salir a comprar para tomar el control.
Por ejemplo, el add-on SingleFile sí necesita permisos de acceso, porque tiene que inspeccionar el DOM renderizado y guardarlo como archivo. Pero me pregunto por qué tiene que acceder a todo. ¿No se podrían conceder permisos como
snapshot DOM onceowrite to a single file?En ese momento probablemente no pude explicar ni entender bien por qué, pero lo trataron como un deseo absurdo. Me alegra ver ahora que quizá simplemente estaba desfasado unos 10 años con la época.
KOReader es menos amigable, pero ofrece más control. Puedes elegir entre varios archivos CSS incluidos o incluso escribir el tuyo.
Entre las ventajas de KOReader también están su excelente soporte para OPDS y un servidor de sincronización autoalojado fácil de usar.
Con esa función, en las páginas que usan este sistema ya no hace falta SinglePage.
Al ver esa parte volví a fijarme. Es la parte que dice: “Por eso decidí crear Bene, un sistema de lectura de EPUB más ligero. Es lo que están usando ahora. Este documento es un EPUB y se puede descargar con el botón de la esquina superior derecha”.
Al leerlo en un navegador de escritorio, no me di cuenta en absoluto hasta que me lo señalaron directamente. En móvil, el encabezado ocupa más pantalla y se nota más, pero fuera de eso se comporta casi como una página web normal.
Probablemente sea una buena señal.
A diferencia de lo que dijeron algunos comentarios, no vi —o al menos no noté— ningún spinner al cargar el documento por primera vez. En el teléfono sí apareció, pero pasó bastante rápido. No sé si eso era la carga del programa WASM o si solo ocurre en la primera carga.
A diferencia de una página web normal o un PDF, parece que no empieza a renderizar hasta que se descargan todos los recursos, es decir, todo el ePub.
Una diferencia que pensé que el artículo trataría, pero no trató, es el rendimiento. Los PDF pueden optimizarse para que las páginas sean bastante independientes, lo que permite renderizado progresivo, acceso aleatorio y alta paralelización.
Incluso solo por el hecho de que los navegadores no puedan abrir EPUB, se siente como un proyecto un tanto condenado al fracaso. Si enlazas un PDF, aunque haya un pequeño cambio de contexto, el navegador lo abre y lo muestra.
Según la descripción, EPUB es básicamente HTML, así que es raro que el navegador no lo abra, pero no parece fácil convencer a los burócratas de Chrome/Mozilla.
Otro punto desalentador es que HTML y CSS se volvieron tan enormes e inflados que casi no hay gente capaz de implementar un “lector” para EPUB/HTML. En la práctica se vuelve “implementa un navegador nuevo”. A largo plazo parece más viable algo como Djot, un Markdown fácil de parsear con un poco de capacidad de renderizado encima.
Mi solución provisional personal es meter CSS, SVG, scripts e incluso imágenes base64 en un solo archivo HTML. Es parecido a EPUB, algo inflado y feo, pero con un poco de cuidado funciona y el navegador puede abrirlo de forma natural.
Sin embargo, el usuario no tiene forma de saber que “puede descargar esta página web y guardarla offline”. Sería bueno tener una extensión como
.htmlsque indique que es un HTML sin recursos externos.No parece haber razón para que los navegadores no puedan hacer lo mismo con EPUB. Ya existen extensiones de navegador que hacen exactamente eso. El problema es si el formato EPUB gana popularidad.
Luego se “necesitaron” diseños y layouts tipo revista, pero seguía siendo bastante decente porque todavía estaba basado en documentos.
Después se intentó encajar HTML a la fuerza como plataforma de distribución de aplicaciones. El layout CSS actual por fin se acercó más a los motores de layout tradicionales de aplicaciones.
Creo que los últimos 20 años se desperdiciaron en gran medida por no tener una forma adecuada de distribuir aplicaciones multiplataforma. Salvo Java.
Para que este formato funcione de manera repetible en todas partes, debe estandarizarse y también debe ser fácil implementar nuevos motores de renderizado. Depender de webviews no se siente como el camino a seguir.
La belleza de PDF está en que es muy confiable. Un PDF de hace 10 años se renderiza hoy exactamente igual que antes.
Para que este esfuerzo tenga éxito, creo que habría que reducir mucho el alcance del documento. El subconjunto permitido de XHTML debería ser muy limitado, y se debería priorizar la capacidad de renderizarse con el mismo aspecto en todas partes. Primero un layout fijo con tamaño de página fijo, y después documentos con reflow. También hace falta un estándar que incluya documentos de prueba exhaustivos y salidas de renderizado.
Si no hay soporte del navegador, no sería tan difícil escribir un proxy del lado del servidor que convierta un EPUB en un sitio navegable, con controles para cambiar de capítulo y algunas opciones simples de layout.
Claro que el soporte de DRM necesario para ver la mayoría de los ebooks comerciales con ese proxy probablemente sería muy problemático legalmente.
Pensándolo bien, el soporte de EPUB con DRM aprobado por editoriales en el navegador está técnicamente a medio paso del soporte de DRM para páginas web normales, lo cual es una perspectiva bastante horrible.
Creo que PDF es un formato legacy terrible, con complejidad innecesaria. Como la mayoría de los usos de PDF no tienen que ver con impresión, la lógica de composición tipográfica tampoco me convence.
En la gran mayoría de los casos de uso, es mucho más importante que sea fácil de leer en teléfonos, tablets y computadoras.
Me sorprendió que el autor dijera que iBooks no soporta vista con desplazamiento, así que lo comprobé. iBooks en macOS no soporta desplazamiento para archivos ePub, pero sí lo soporta en iOS y iPadOS. Una decisión muy extraña de Apple.
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Nunca he visto documentación técnica distribuida en un formato que no sea PDF y que fuera cómoda de leer y buscar. Ni siquiera en el teléfono.
No quiero documentos cuya apariencia cambie según un estado transitorio como el dispositivo de lectura o el tamaño de la ventana. Quiero documentos con un layout fijo, bien diseñado por el autor.
Incluso al leer en una pantalla o ventana pequeña, si no es un documento de texto simple, quiero un lector inteligente con zoom y desplazamiento rápidos, no cambios de layout. No debería tener comportamientos tontos como algunos lectores de Android, donde el scroll vertical o Page Up/Page Down también mueven la posición horizontal y hacen difícil leer columnas de texto.
Con solo respetar las recomendaciones tradicionales de ancho máximo para columnas de texto, alcanza para leer cómodamente en un teléfono. Leer en el teléfono solo se vuelve incómodo cuando el autor crea columnas demasiado anchas y rompe las reglas tradicionales de tipografía.
Por eso creo que es mala idea intentar crear un solo estándar que sirva para todo. Sería mejor tener dos estándares de documentos digitales. Uno con capacidades completas de multimedia e interacción, excepto networking; y otro como subconjunto de ese, en blanco y negro, sin multimedia, con interacción limitada principalmente a hipervínculos dentro del documento.
Y, de hecho, ya existen casi esos dos formatos. HTML, MHTML=EML y EPUB.
Por supuesto, también hace falta un tercer formato para conservación física y para los raros documentos digitales de layout fijo, y PDF/A ya parece cumplir bastante bien ese rol.
Quizás SVG multipágina también podría servir, pero para imprimir correctamente varias páginas parece que al final habría que exportar primero a PDF. Lo digo pensando en Inkscape.
Hace 8 días hubo un artículo titulado “Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)” que recibió 134 puntos
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
Me pregunto qué ofrece un lector EPUB que no tenga un navegador. Por ahora, la respuesta parece ser una sola cosa, y menor: poder tratar un archivo .epub, es decir, un archivo zip, como un directorio
Si esa es realmente la única diferencia entre un lector EPUB y un subconjunto del navegador, la forma más simple y de menor esfuerzo sería esta:
hacer que los navegadores existentes traten los archivos zip como directorios bajo ciertas condiciones.
Definir una restricción de HTML verificable mecánicamente que garantice recursos completamente locales, como dice el artículo original. Podría bastar con exigir que todas las URL, salvo los enlaces, sean rutas relativas.
Declarar como “EPUB portátiles” los archivos zip que cumplan esta restricción.
Olvidarse por completo de los lectores EPUB dedicados, existentes o nuevos.
Para los recursos completamente locales, me gustaría ver el requisito de que todos los objetos tengan una opción de reemplazo disponible localmente. Por ejemplo, si no se puede obtener esa fuente, se usa una fuente estándar. Aunque no se vea perfecto, si se limita dentro del alcance de las alternativas debería funcionar razonablemente bien
Hay un modo de falla que todavía no se ha tratado lo suficiente: las imágenes que no funcionan bien. Fundamentalmente, las imágenes no se pueden refluir. En gran medida esto podría resolverse usando SVG, pero no cuando se trata de imágenes ráster reales. Al final, probablemente no quede otra que ofrecer varias resoluciones
También me encontré con un problema relacionado y todavía no he visto una buena respuesta: un SVG que sea consciente de la resolución y, cuando haya suficiente resolución disponible, traiga una imagen más detallada. Si dibujas líneas subpíxel se ven borrosas, pero al ampliar esa misma imagen esas líneas se vuelven útiles. Los íconos de Windows reconocen esto al poder incluir varias resoluciones y usar la adecuada según el contexto
El autor es investigador posdoctoral bajo la supervisión de Shriram Krishnamurthi. Shriram Krishnamurthi es autor de Programming Languages: Application and Interpretation(PLAI) y coautor de Data-Centric Introduction to Computing(DCIC)
Ahora estoy leyendo tanto PLAI como DCIC, y me impresiona mucho el cuidado minucioso que los autores pusieron para convertirlos en obras de arte educativas. Eso sí que es cariño
https://willcrichton.net/
https://rust-book.cs.brown.edu/
Los PDF pueden incluir fuentes, pero con frecuencia no lo hacen y dependen de las fuentes del sistema. Una razón es que meter las fuentes en el PDF puede aumentar mucho el tamaño del archivo. En algunos casos, una sola fuente puede ser más grande que el resto del archivo completo
Una vez implementé la incrustación de fuentes en software que generaba PDF, y fue sorprendentemente difícil descubrir cómo hacer que funcionara de forma confiable
Que los PDF se rendericen de manera consistente tampoco es tan cierto como uno podría pensar. Varias veces vi que el mismo PDF se renderizaba de forma distinta según el visor de PDF usado. Por lo general las diferencias son sutiles, pero a veces hay casos límite con diferencias bastante grandes. También me pasó que la misma versión de Acrobat Reader renderizara un PDF de forma distinta según el sistema operativo
Por lo tanto, si se usan fuentes del sistema compatibles, el diseño del documento renderizado no debería cambiar. Claro que hay casos de fuentes del sistema que se promocionan como compatibles en métricas con las antiguas fuentes Adobe PostScript, pero tienen diferencias sutiles
Salvo por el pequeño conjunto de fuentes estándar del sistema, los documentos PDF normalmente incluyen solo el subconjunto de glifos correspondiente a los caracteres usados en el texto real, no la fuente completa
Fue un The Daily WTF de la vida cotidiana