Je m’intéresse beaucoup à l’intersection entre ebooks, sécurité et web LowJS, donc ce sujet me paraît important
Il faut bien un format d’ebook portable sous forme de fichier unique, mais le PDF n’est pas la solution, car il ne permet pas la redistribution du texte
En 2024, HTML+CSS peut reproduire presque tous les supports imprimés tout en permettant la redistribution du texte
Je ne pense pas que JavaScript doive être indispensable. Un ebook devrait être un livre dont la taille peut être modifiée de façon significative, et ses fonctions de base de livre devraient fonctionner même avec JavaScript désactivé. Si de l’interaction ou des enrichissements sont nécessaires, on peut utiliser JavaScript, mais si le livre ne fonctionne pas sans JavaScript, je considère cela comme un bug
Mettre tous les styles en inline est, à mon avis, une erreur, car cela peut casser la CSP de certains utilisateurs. Il faudrait séparer les styles dans des ressources avec des chemins relatifs à la base HTML, et l’ebook devrait interdire le chargement de ressources depuis d’autres domaines
Enfin, il suffit de le distribuer sous forme de fichier zip. J’ai l’impression que les ebooks fonctionnent déjà un peu comme ça
Dire que « les ebooks fonctionnent déjà comme des zip » est vrai dans une certaine mesure. Les outils unzip peuvent extraire les fichiers EPUB, et si nécessaire on peut changer l’extension de .epub à .zip
Mais l’inverse n’est pas forcément vrai. Même si un ensemble de fichiers était un EPUB valide avant extraction, le rezippper n’importe comment peut produire un EPUB invalide
Dans un zip EPUB, le fichier mimetype est particulier : il doit être le premier élément de l’archive, son contenu doit être uniquement application/epub+zip, et il doit être stocké sans compression
Étonnamment, beaucoup d’outils zip rendent cela pénible, soit en changeant l’ordre des fichiers, soit en rendant difficile le fait de stocker seulement certains fichiers sans compression. Les programmes zip en ligne de commande le permettent généralement avec des options, mais dans les bibliothèques zip c’est assez douloureux. Je parle d’expérience, pour avoir créé un logiciel de génération d’EPUB
Il est important de distinguer les fichiers zip ordinaires des ebooks. Il suffit d’utiliser l’extension .epub
Ce qui est décrit, c’est le format ePub, où les fichiers HTML, CSS et images sont placés dans une archive zip
Je me demande ce que vaudrait un ZIP auto-extractible. Par exemple comme cette page : https://gildas-lormeau.github.io/
Elle inclut aussi une CSP pour le rendre sûr
Je n’aime pas trop l’approche consistant à tout mettre dans un zip
Ce que j’appréciais dans les anciens fichiers .doc par rapport aux .docx, c’est qu’on pouvait rechercher très rapidement un mot donné dans un dossier contenant des centaines ou des milliers de fichiers. Avec le format zip, ce n’est pas possible
Je viens d’enregistrer un fichier en .doc et de l’ouvrir dans un éditeur hexadécimal : le contenu réel y était bien en texte brut. Les formats zip ou PDF sont difficiles à rechercher avec grep, et je doute qu’une compression soit vraiment nécessaire pour quelques milliers de caractères de texte
À propos de l’idée que « HTML+CSS en 2024 peut reproduire presque tous les supports imprimés », ceci vaut aussi le détour : https://www.princexml.com/samples/
C’est un article très bien construit, écrit par le développeur de Nota, qui cherche à amener le format EPUB au niveau du PDF. Il a déjà créé une visionneuse, et l’article lui-même est affiché via un port WASM de cette visionneuse basé sur le navigateur
L’un des problèmes est de savoir avec quelle précision l’EPUB, qui est en pratique du XHTML, peut reproduire une mise en page. Le critère de l’article original est que le document ait une apparence « plausible », mais pour rivaliser avec le PDF, il semble suggérer qu’il faudrait à HTML de nouvelles fonctionnalités de mise en page, au moins du côté des retours à la ligne
Je vois deux voies de progrès. L’une consiste à ce que les navigateurs fournissent davantage d’outils typographiques ; text-wrap: pretty est censé aider, mais lors d’un bref test je n’ai pas eu l’impression que la qualité des retours à la ligne s’améliorait. L’autre consiste à précalculer les retours à la ligne, mais ce n’est possible que dans un rendu à mise en page fixe
L’auteur mentionne aussi les annotations, mais je ne vois pas bien comment il compte les implémenter
L’auteur traite aussi des EPUB à mise en page fixe. EPUB peut définir la pagination par défaut, les retours à la ligne, les polices, la taille des polices, la taille des pages, la position des images, etc., afin que le rendu soit identique partout
C’est déjà possible avec EPUB3, mais l’inconvénient est que le rendu n’est pas agréable sur des écrans comme ceux des téléphones. Selon le lecteur, on peut remplacer les valeurs par défaut, mais il faut alors espérer que le lecteur reconstruise le document de manière agréable
Une alternative serait qu’un EPUB spécifie plusieurs rendus selon les types d’écrans courants. Ce n’est pas parfait, mais laisser l’auteur du document fournir des valeurs par défaut tout en permettant à l’utilisateur de les remplacer s’il le souhaite me semble être un bon compromis
Le PDF n’a pas de fonction de redistribution des lignes. Il ressemble davantage à un format graphique, proche du SVG, mais plus rigide, et ne permet donc pas quelque chose comme la redistribution du texte
Ce qu’il faut à un format d’ebook, c’est un balisage sémantique qui s’adapte à l’appareil de rendu. HTML+CSS a été créé précisément dans ce but
Les concepteurs de mise en page de livres doivent donc consciemment céder au lecteur une partie du contrôle sur l’apparence du livre. Quelques imperfections visuelles sont un prix acceptable à payer. Si l’on a besoin d’une perfection visuelle, on peut utiliser le PDF
Bien sûr, cela se complique avec des éléments interactifs. Les gros éléments interactifs devraient s’ouvrir dans une vue dédiée lorsque nécessaire, tandis que les petits devraient accepter la redistribution
Il me semble que CSS prend déjà en charge, fondamentalement, les fonctionnalités de mise en page pour médias paginés. Ne suffirait-il pas que les lecteurs EPUB implémentent un mode d’affichage classique de type « aperçu avant impression » ?
Ironiquement, l’exemple d’annotation donné par l’auteur ne fonctionne pas correctement dans mon environnement. Sur Firefox Android avec écran tactile, un appui long affiche un lien au lieu d’une pop-up
Les annotations et les références font déjà partie de la spécification EPUB, et peut-être même de la spécification HTML, il me semble
Je ne suis pas non plus d’accord pour dire qu’un appui long déclenchant une pop-up est préférable à une ancre de lien hypertexte classique. Si la fonction « retour » du lecteur fonctionne correctement, ou si les références bidirectionnelles disposent d’un lien « retour », la navigation est beaucoup moins intrusive
Il existait autrefois quelque chose appelé XSL Formatting Objects(XSL-FO). Cela visait une sorte de PDF basé sur XML, mais à un niveau plus élevé, ce qui permettait aussi la redistribution du texte
L’idée était de distribuer ensemble un document XML et une feuille de style XSL, de les transformer en FO pour le rendu, et de pouvoir fournir plusieurs feuilles de style pour le même document selon l’appareil cible ou la taille de page
Dans Firefox, j’utilise l’extension SinglePage pour enregistrer le DOM de la page courante sous forme de fichier HTML autonome. Elle inline les CSS et les images via des URL data:, et supprime les dépendances ainsi que les scripts.
Ce n’est pas parfait, et je ne crois pas que les navigateurs maintiendront toujours la rétrocompatibilité, mais je préfère ça plutôt que d’enregistrer une page en PDF ou en plusieurs fichiers.
Fait intéressant, l’une des rares pages où cette extension a échoué était justement cet article sur les EPUB portables. Il semble qu’il y ait trop de magie pour obtenir la mise en forme. La page enregistrée était lisible, mais le style n’avait plus rien à voir avec l’original.
J’aime le fait que fbreader sur Android affiche tous les livres de la même façon, selon les réglages de l’application, plutôt qu’avec le style du fichier EPUB. Je ne l’ai jamais vu appliquer du CSS ni tenter d’exécuter des scripts inclus dans le fichier, et j’espère que cela continuera. Charger des dépendances externes est une idée encore pire, et je ne savais même pas que c’était autorisé au départ.
Je pense que vous parlez de SingleFile.
À ce sujet, le système de permissions des extensions Firefox est étrange. Pour faire quoi que ce soit d’un peu intéressant, on finit par devoir demander presque toutes les permissions, ce qui crée naturellement un marché où des acteurs malveillants cherchent des extensions à racheter.
Par exemple, l’extension SingleFile doit regarder le DOM rendu et l’enregistrer dans un fichier, donc elle a effectivement besoin d’un accès. Mais pourquoi doit-elle accéder à tout ? Ne pourrait-on pas accorder seulement des permissions comme snapshot DOM once, write to a single file ?
Il me semble que l’un de mes tout premiers commentaires sur HN, il y a environ dix ans, disait que je voulais enregistrer les pages web HTML en HTML, et non en PDF.
À l’époque, je n’aurais sans doute pas su en expliquer la raison, ni même vraiment la comprendre, mais cela avait été traité comme un souhait absurde. Avec le recul, je suis content de voir que j’étais simplement décalé d’une dizaine d’années par rapport à mon époque.
La raison pour laquelle cette page est difficile à parser est bien expliquée par un autre commentaire. C’est un texte du développeur de Nota sur sa volonté de hisser EPUB au même niveau que PDF, et le texte lui-même est affiché dans une visionneuse basée sur WASM dans le navigateur.
FBReader utilise par défaut le CSS du document. Si je me souviens bien, il faut environ quatre étapes pour le désactiver.
KOReader est moins convivial, mais offre davantage de contrôle. On peut choisir un fichier précis parmi plusieurs fichiers CSS fournis, ou même écrire le sien.
Parmi les avantages de KOReader, il y a aussi son excellent support d’OPDS et un serveur de synchronisation auto-hébergeable facile à mettre en place.
Cet article comporte un bouton de téléchargement EPUB.
Avec cette fonctionnalité, les pages qui utilisent ce système n’ont plus besoin de SinglePage.
Cette partie m’a fait y regarder de nouveau. C’est le passage qui dit : « Nous avons donc décidé de créer Bene, un système de lecture EPUB plus léger. C’est ce que vous utilisez en ce moment. Ce document est un EPUB, et vous pouvez le télécharger avec le bouton en haut à droite. »
En lisant sur un navigateur de bureau, je ne m’en étais absolument pas rendu compte avant qu’on me le dise directement. Sur mobile, l’en-tête occupe davantage l’écran et se remarque plus, mais à part ça, cela se comporte presque comme une page web ordinaire.
C’est probablement bon signe.
Contrairement à ce que disent certains commentaires, je n’ai pas vu de spinner, ou du moins je ne l’ai pas remarqué, lors du chargement initial du document. Sur téléphone, je l’ai vu, mais il est passé assez vite. Je ne sais pas si c’est le chargement du programme WASM, ni si cela ne se produit qu’au premier chargement.
Ce que le spinner attend principalement, c’est le téléchargement du fichier .epub. Le fichier fait 4,77 Mo, donc c’est assez lourd sans connexion rapide. Après décompression, l’essentiel du volume est occupé par les images, environ 99 %.
Contrairement à une page web classique ou à un PDF, le rendu ne semble pas commencer tant que tous les assets, c’est-à-dire l’ePub complet, n’ont pas été téléchargés.
Une différence que je m’attendais à voir abordée dans l’article, mais qui ne l’est pas, est la performance. Les PDF peuvent être optimisés pour que les pages soient assez indépendantes, ce qui permet un rendu progressif, un accès aléatoire et une forte parallélisation.
Sur téléphone, je ne m’en étais absolument pas rendu compte avant de lire l’article. Je pensais simplement que c’était une page web ordinaire présentant le projet.
Le simple fait que les navigateurs ne puissent pas ouvrir les EPUB donne déjà l’impression d’un projet quelque peu voué à l’échec. Un PDF, si on le met en lien, le navigateur l’ouvre et l’affiche, même s’il y a un léger changement de contexte
D’après la description, l’EPUB est en fait du HTML, donc il est étrange que les navigateurs ne l’ouvrent pas, mais convaincre les bureaucraties de Chrome/Mozilla ne sera sans doute pas facile
Autre point décourageant : HTML et CSS sont devenus tellement énormes et boursouflés que presque personne ne peut implémenter un « lecteur » pour EPUB/HTML. En pratique, cela revient à « implémenter un nouveau navigateur ». Une approche consistant à ajouter quelques capacités de rendu à un Markdown facile à parser, comme Djot, semble plus prometteuse à long terme
Mon compromis provisoire personnel consiste à tout mettre — CSS, SVG, scripts et même images en base64 — dans un unique fichier HTML. C’est proche de l’EPUB, un peu lourd et laid, mais avec un peu d’attention ça fonctionne, et le navigateur peut l’ouvrir naturellement
En revanche, l’utilisateur n’a aucun moyen de savoir qu’il peut « télécharger cette page web et la conserver hors ligne ». Ce serait bien d’avoir une extension comme .htmls indiquant qu’il s’agit d’un HTML sans ressource externe
Il n’y a pas si longtemps, les navigateurs ne savaient pas non plus ouvrir les PDF. Aujourd’hui, tous les navigateurs intègrent un lecteur PDF écrit en ASM/JS
Je ne vois pas pourquoi les navigateurs ne pourraient pas faire la même chose pour l’EPUB. Il existe déjà des extensions de navigateur qui font exactement cela. La question est de savoir si le format EPUB gagnera en popularité
HTML était à l’origine de l’hypertexte. Quelques liens, des dessins/images, des tableaux, à peu près
Puis on a eu « besoin » de designs et de mises en page façon magazine, mais comme cela restait centré sur le document, c’était encore assez correct
Ensuite, on a essayé de forcer HTML à devenir une plateforme de distribution d’applications. Les layouts CSS actuels se sont enfin rapprochés des moteurs de mise en page d’applications traditionnels
À mon avis, les vingt dernières années ont été en grande partie gaspillées faute d’un bon mode de distribution d’applications multiplateforme. À l’exception de Java
Donc cet article lui-même semble être un EPUB ouvert dans un visualiseur EPUB en WASM
Le principal obstacle me semble être le périmètre d’implémentation de HTML/CSS. L’auteur dit : « Principe de génération de HTML portable : si possible, un système qui génère des EPUB portables doit produire du HTML portable », mais je n’ai pas l’impression qu’il soit allé assez loin
Pour que ce format se comporte de manière reproductible partout, il doit être standardisé et il doit être facile d’implémenter de nouveaux moteurs de rendu. S’appuyer sur des webviews ne me paraît pas être la voie à suivre
La beauté du PDF tient au fait qu’il est très fiable. Un PDF d’il y a dix ans se rend aujourd’hui exactement comme avant
Pour que cet effort réussisse, il faudrait sans doute réduire fortement le périmètre des documents. Le sous-ensemble XHTML autorisé devrait être très limité, et la priorité devrait être la capacité à obtenir le même rendu partout. D’abord une mise en page fixe avec taille de page fixe, puis seulement des documents reflowables. Il faudrait aussi une norme incluant des documents de test complets et leurs sorties de rendu
Même si les navigateurs ne fournissent pas d’UI pratique pour ouvrir les EPUB, ils ne devraient avoir aucun problème à rendre les fichiers HTML par chapitre qui se trouvent à l’intérieur
En l’absence de prise en charge par les navigateurs, il ne serait pas très difficile d’écrire un proxy côté serveur qui transforme un EPUB en site navigable, avec des contrôles de changement de chapitre et quelques options simples de mise en page
Bien sûr, pour lire la plupart des livres numériques commerciaux via un tel proxy, la prise en charge du DRM nécessaire risquerait d’être très problématique juridiquement
À bien y réfléchir, la prise en charge par les navigateurs des EPUB avec DRM approuvés par les éditeurs ne serait techniquement qu’à un demi-pas de la prise en charge du DRM pour les pages web ordinaires, ce qui est une perspective assez effrayante
Je considère le PDF comme un terrible format legacy, avec une complexité inutile. La plupart des usages du PDF n’ayant rien à voir avec l’impression, la logique de composition ne me parle pas
Dans la grande majorité des cas, il est bien plus important que ce soit facile à lire sur téléphone, tablette et ordinateur
L’auteur disait qu’iBooks ne prenait pas en charge l’affichage en défilement, ce qui m’a surpris, alors j’ai vérifié. iBooks sur macOS ne prend pas en charge le défilement des fichiers ePub, mais iOS et iPadOS le prennent en charge. C’est une décision très étrange de la part d’Apple https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
La spécification PDF est pénible, mais il n’existe absolument rien pour la remplacer
Je n’ai jamais vu de documentation technique distribuée dans un format autre que PDF qui soit agréable à lire et à rechercher. Même sur téléphone
Je ne veux pas de documents dont l’apparence change en fonction d’un état temporaire comme l’appareil de lecture ou la taille de la fenêtre. Je veux un document à mise en page fixe, bien conçu par son auteur
Même pour lire sur un petit écran ou dans une petite fenêtre, si ce n’est pas un simple document texte, je veux un lecteur intelligent avec zoom et déplacement rapides, plutôt qu’un changement de mise en page. Il ne doit pas avoir de comportements stupides comme certains lecteurs Android où le défilement vertical ou Page Up/Page Down déplacent aussi la position horizontale, rendant les colonnes de texte difficiles à lire
Le simple respect des recommandations traditionnelles sur la largeur maximale des colonnes de texte suffit à rendre la lecture confortable sur téléphone. La lecture sur téléphone ne devient pénible que lorsque l’auteur crée des colonnes beaucoup trop larges et enfreint les règles typographiques traditionnelles
La raison de vouloir des documents à mise en page fixe n’est pas seulement l’impression. C’est parce qu’il est plus important de figer la mise en page du document que de s’adapter aux petits écrans
Je ne connais pas ce cas précis, mais certains lecteurs peuvent agir ainsi par souci de cohérence avec les appareils à encre électronique. Sur l’encre électronique, le défilement est limité matériellement à cause du faible taux de rafraîchissement, des processeurs peu puissants et de l’économie de batterie
C’est pourquoi essayer de créer un standard unique adapté à tout me semble être une mauvaise idée. Pour les documents numériques, deux standards vaudraient mieux. L’un serait un format avec multimédia complet et interactions, sauf le réseau ; l’autre serait un sous-ensemble limité au noir et blanc, sans multimédia, avec des interactions essentiellement restreintes aux hyperliens internes au document
Et nous avons déjà presque ces deux formats : HTML, MHTML=EML, et EPUB
Bien sûr, il faut aussi un troisième format pour l’archivage physique et les rares documents numériques à mise en page fixe, rôle que PDF/A semble déjà plutôt bien remplir
Si l’on doit vraiment imprimer quelque chose, le PDF reste la voie la plus fiable et la plus portable
Le SVG multipage serait peut-être possible, mais pour imprimer correctement plusieurs pages, il faudrait probablement finir par exporter d’abord en PDF. Je dis cela en pensant à Inkscape
Je me demande ce qu’un lecteur EPUB apporte qu’un navigateur n’a pas. À première vue, il n’y a qu’une seule réponse, assez mineure : les fichiers .epub, c’est-à-dire la possibilité de traiter des fichiers zip comme des répertoires
Si c’est vraiment la seule différence entre un lecteur EPUB et un sous-ensemble de navigateur, l’approche la plus simple et la moins coûteuse serait la suivante
Faire en sorte que les navigateurs existants traitent, sous certaines conditions, les fichiers zip comme des répertoires
Définir une restriction HTML vérifiable mécaniquement qui garantisse les ressources entièrement locales mentionnées dans l’article original. Exiger que toutes les URL, sauf les liens, soient des chemins relatifs pourrait suffire
Déclarer les fichiers zip qui respectent cette restriction comme des « EPUB portables »
Oublier tous les lecteurs EPUB dédiés, existants ou nouveaux
D’accord. Ça ressemble à la vraie solution
Pour les ressources entièrement locales, j’aimerais voir une exigence selon laquelle chaque objet doit disposer d’une solution de repli disponible localement. Par exemple, utiliser une police standard si la police en question ne peut pas être récupérée. Ce ne sera pas parfait visuellement, mais si l’on reste dans les limites prévues pour les solutions de repli, cela devrait fonctionner raisonnablement
Il reste un mode de défaillance qui n’a pas encore été suffisamment traité : les images qui ne fonctionnent pas correctement. Fondamentalement, les images ne se redistribuent pas avec le texte. On peut en résoudre une bonne partie avec du SVG, mais pas quand il s’agit de vraies images raster. Au final, il faudra probablement fournir plusieurs résolutions
J’ai aussi rencontré un problème lié, sans encore voir de bonne réponse : un SVG conscient de la résolution, qui charge une image plus détaillée lorsqu’une résolution suffisante est disponible. Si l’on trace des lignes sous-pixel, elles deviennent floues, mais si l’on agrandit la même image, ces lignes deviennent utiles. Les icônes Windows reconnaissent ce problème en pouvant inclure plusieurs résolutions et utiliser celle qui convient au contexte
L’auteur est postdoctorant sous la direction de Shriram Krishnamurthi. Shriram Krishnamurthi est l’auteur de Programming Languages: Application and Interpretation(PLAI) et l’un des auteurs de Data-Centric Introduction to Computing(DCIC)
Je suis en train de lire PLAI et DCIC, et je suis vraiment impressionné par le soin minutieux que les auteurs ont apporté pour en faire des œuvres d’art pédagogiques. C’est une vraie marque d’affection https://willcrichton.net/
Les PDF peuvent inclure des polices, mais ils ne le font souvent pas et s’appuient sur les polices du système. L’une des raisons est que l’intégration de polices dans un PDF peut fortement augmenter la taille du fichier. Dans certains cas, une seule police peut être plus volumineuse que tout le reste du fichier
J’ai déjà implémenté l’incorporation de polices dans un logiciel qui générait des PDF, et trouver comment la faire fonctionner de manière fiable s’est révélé étonnamment difficile
Le rendu cohérent des PDF n’est pas non plus aussi garanti qu’on le pense. J’ai vu plusieurs cas où le même PDF était rendu différemment selon le lecteur PDF utilisé. En général, les différences sont subtiles, mais il existe parfois des cas limites où elles sont assez importantes. J’ai même vu la même version d’Acrobat Reader rendre un PDF différemment selon le système d’exploitation
Il n’y a que quelques polices système standard qui peuvent être omises d’un fichier PDF, et le document suppose que les polices utilisées pour le rendu ont les mêmes métriques que les polices traditionnelles comme Times, Helvetica ou Courier
Ainsi, avec des polices système compatibles, la mise en page du document rendu ne devrait pas changer. Bien sûr, il existe des cas de polices système présentées comme compatibles en métriques avec les anciennes polices Adobe PostScript, tout en présentant de subtiles différences
Hormis le petit nombre de polices système standard, les documents PDF incluent généralement non pas toute la police, mais seulement le sous-ensemble de glyphes correspondant aux caractères effectivement utilisés dans le texte
Pendant plus de 20 ans, j’ai cru que les PDF se rendaient de manière cohérente, jusqu’à ce qu’on me dise en entretien que mon document s’affichait bizarrement, et que je découvre alors que des polices pouvaient manquer
C’était un The Daily WTF du quotidien
Je me demande s’il existe un logiciel qui réduit les polices au minimum en supprimant les points de code non utilisés dans le document
1 commentaires
Avis sur Hacker News
Je m’intéresse beaucoup à l’intersection entre ebooks, sécurité et web LowJS, donc ce sujet me paraît important
Il faut bien un format d’ebook portable sous forme de fichier unique, mais le PDF n’est pas la solution, car il ne permet pas la redistribution du texte
En 2024, HTML+CSS peut reproduire presque tous les supports imprimés tout en permettant la redistribution du texte
Je ne pense pas que JavaScript doive être indispensable. Un ebook devrait être un livre dont la taille peut être modifiée de façon significative, et ses fonctions de base de livre devraient fonctionner même avec JavaScript désactivé. Si de l’interaction ou des enrichissements sont nécessaires, on peut utiliser JavaScript, mais si le livre ne fonctionne pas sans JavaScript, je considère cela comme un bug
Mettre tous les styles en inline est, à mon avis, une erreur, car cela peut casser la CSP de certains utilisateurs. Il faudrait séparer les styles dans des ressources avec des chemins relatifs à la base HTML, et l’ebook devrait interdire le chargement de ressources depuis d’autres domaines
Enfin, il suffit de le distribuer sous forme de fichier zip. J’ai l’impression que les ebooks fonctionnent déjà un peu comme ça
Mais l’inverse n’est pas forcément vrai. Même si un ensemble de fichiers était un EPUB valide avant extraction, le rezippper n’importe comment peut produire un EPUB invalide
Dans un zip EPUB, le fichier mimetype est particulier : il doit être le premier élément de l’archive, son contenu doit être uniquement
application/epub+zip, et il doit être stocké sans compressionÉtonnamment, beaucoup d’outils zip rendent cela pénible, soit en changeant l’ordre des fichiers, soit en rendant difficile le fait de stocker seulement certains fichiers sans compression. Les programmes zip en ligne de commande le permettent généralement avec des options, mais dans les bibliothèques zip c’est assez douloureux. Je parle d’expérience, pour avoir créé un logiciel de génération d’EPUB
Ce qui est décrit, c’est le format ePub, où les fichiers HTML, CSS et images sont placés dans une archive zip
Elle inclut aussi une CSP pour le rendre sûr
Ce que j’appréciais dans les anciens fichiers .doc par rapport aux .docx, c’est qu’on pouvait rechercher très rapidement un mot donné dans un dossier contenant des centaines ou des milliers de fichiers. Avec le format zip, ce n’est pas possible
Je viens d’enregistrer un fichier en .doc et de l’ouvrir dans un éditeur hexadécimal : le contenu réel y était bien en texte brut. Les formats zip ou PDF sont difficiles à rechercher avec grep, et je doute qu’une compression soit vraiment nécessaire pour quelques milliers de caractères de texte
C’est un article très bien construit, écrit par le développeur de Nota, qui cherche à amener le format EPUB au niveau du PDF. Il a déjà créé une visionneuse, et l’article lui-même est affiché via un port WASM de cette visionneuse basé sur le navigateur
L’un des problèmes est de savoir avec quelle précision l’EPUB, qui est en pratique du XHTML, peut reproduire une mise en page. Le critère de l’article original est que le document ait une apparence « plausible », mais pour rivaliser avec le PDF, il semble suggérer qu’il faudrait à HTML de nouvelles fonctionnalités de mise en page, au moins du côté des retours à la ligne
Je vois deux voies de progrès. L’une consiste à ce que les navigateurs fournissent davantage d’outils typographiques ;
text-wrap: prettyest censé aider, mais lors d’un bref test je n’ai pas eu l’impression que la qualité des retours à la ligne s’améliorait. L’autre consiste à précalculer les retours à la ligne, mais ce n’est possible que dans un rendu à mise en page fixeL’auteur mentionne aussi les annotations, mais je ne vois pas bien comment il compte les implémenter
C’est déjà possible avec EPUB3, mais l’inconvénient est que le rendu n’est pas agréable sur des écrans comme ceux des téléphones. Selon le lecteur, on peut remplacer les valeurs par défaut, mais il faut alors espérer que le lecteur reconstruise le document de manière agréable
Une alternative serait qu’un EPUB spécifie plusieurs rendus selon les types d’écrans courants. Ce n’est pas parfait, mais laisser l’auteur du document fournir des valeurs par défaut tout en permettant à l’utilisateur de les remplacer s’il le souhaite me semble être un bon compromis
Ce qu’il faut à un format d’ebook, c’est un balisage sémantique qui s’adapte à l’appareil de rendu. HTML+CSS a été créé précisément dans ce but
Les concepteurs de mise en page de livres doivent donc consciemment céder au lecteur une partie du contrôle sur l’apparence du livre. Quelques imperfections visuelles sont un prix acceptable à payer. Si l’on a besoin d’une perfection visuelle, on peut utiliser le PDF
Bien sûr, cela se complique avec des éléments interactifs. Les gros éléments interactifs devraient s’ouvrir dans une vue dédiée lorsque nécessaire, tandis que les petits devraient accepter la redistribution
Les annotations et les références font déjà partie de la spécification EPUB, et peut-être même de la spécification HTML, il me semble
Je ne suis pas non plus d’accord pour dire qu’un appui long déclenchant une pop-up est préférable à une ancre de lien hypertexte classique. Si la fonction « retour » du lecteur fonctionne correctement, ou si les références bidirectionnelles disposent d’un lien « retour », la navigation est beaucoup moins intrusive
L’idée était de distribuer ensemble un document XML et une feuille de style XSL, de les transformer en FO pour le rendu, et de pouvoir fournir plusieurs feuilles de style pour le même document selon l’appareil cible ou la taille de page
Dans Firefox, j’utilise l’extension SinglePage pour enregistrer le DOM de la page courante sous forme de fichier HTML autonome. Elle inline les CSS et les images via des URL
data:, et supprime les dépendances ainsi que les scripts.Ce n’est pas parfait, et je ne crois pas que les navigateurs maintiendront toujours la rétrocompatibilité, mais je préfère ça plutôt que d’enregistrer une page en PDF ou en plusieurs fichiers.
Fait intéressant, l’une des rares pages où cette extension a échoué était justement cet article sur les EPUB portables. Il semble qu’il y ait trop de magie pour obtenir la mise en forme. La page enregistrée était lisible, mais le style n’avait plus rien à voir avec l’original.
J’aime le fait que fbreader sur Android affiche tous les livres de la même façon, selon les réglages de l’application, plutôt qu’avec le style du fichier EPUB. Je ne l’ai jamais vu appliquer du CSS ni tenter d’exécuter des scripts inclus dans le fichier, et j’espère que cela continuera. Charger des dépendances externes est une idée encore pire, et je ne savais même pas que c’était autorisé au départ.
À ce sujet, le système de permissions des extensions Firefox est étrange. Pour faire quoi que ce soit d’un peu intéressant, on finit par devoir demander presque toutes les permissions, ce qui crée naturellement un marché où des acteurs malveillants cherchent des extensions à racheter.
Par exemple, l’extension SingleFile doit regarder le DOM rendu et l’enregistrer dans un fichier, donc elle a effectivement besoin d’un accès. Mais pourquoi doit-elle accéder à tout ? Ne pourrait-on pas accorder seulement des permissions comme
snapshot DOM once,write to a single file?À l’époque, je n’aurais sans doute pas su en expliquer la raison, ni même vraiment la comprendre, mais cela avait été traité comme un souhait absurde. Avec le recul, je suis content de voir que j’étais simplement décalé d’une dizaine d’années par rapport à mon époque.
KOReader est moins convivial, mais offre davantage de contrôle. On peut choisir un fichier précis parmi plusieurs fichiers CSS fournis, ou même écrire le sien.
Parmi les avantages de KOReader, il y a aussi son excellent support d’OPDS et un serveur de synchronisation auto-hébergeable facile à mettre en place.
Avec cette fonctionnalité, les pages qui utilisent ce système n’ont plus besoin de SinglePage.
Cette partie m’a fait y regarder de nouveau. C’est le passage qui dit : « Nous avons donc décidé de créer Bene, un système de lecture EPUB plus léger. C’est ce que vous utilisez en ce moment. Ce document est un EPUB, et vous pouvez le télécharger avec le bouton en haut à droite. »
En lisant sur un navigateur de bureau, je ne m’en étais absolument pas rendu compte avant qu’on me le dise directement. Sur mobile, l’en-tête occupe davantage l’écran et se remarque plus, mais à part ça, cela se comporte presque comme une page web ordinaire.
C’est probablement bon signe.
Contrairement à ce que disent certains commentaires, je n’ai pas vu de spinner, ou du moins je ne l’ai pas remarqué, lors du chargement initial du document. Sur téléphone, je l’ai vu, mais il est passé assez vite. Je ne sais pas si c’est le chargement du programme WASM, ni si cela ne se produit qu’au premier chargement.
Contrairement à une page web classique ou à un PDF, le rendu ne semble pas commencer tant que tous les assets, c’est-à-dire l’ePub complet, n’ont pas été téléchargés.
Une différence que je m’attendais à voir abordée dans l’article, mais qui ne l’est pas, est la performance. Les PDF peuvent être optimisés pour que les pages soient assez indépendantes, ce qui permet un rendu progressif, un accès aléatoire et une forte parallélisation.
Le simple fait que les navigateurs ne puissent pas ouvrir les EPUB donne déjà l’impression d’un projet quelque peu voué à l’échec. Un PDF, si on le met en lien, le navigateur l’ouvre et l’affiche, même s’il y a un léger changement de contexte
D’après la description, l’EPUB est en fait du HTML, donc il est étrange que les navigateurs ne l’ouvrent pas, mais convaincre les bureaucraties de Chrome/Mozilla ne sera sans doute pas facile
Autre point décourageant : HTML et CSS sont devenus tellement énormes et boursouflés que presque personne ne peut implémenter un « lecteur » pour EPUB/HTML. En pratique, cela revient à « implémenter un nouveau navigateur ». Une approche consistant à ajouter quelques capacités de rendu à un Markdown facile à parser, comme Djot, semble plus prometteuse à long terme
Mon compromis provisoire personnel consiste à tout mettre — CSS, SVG, scripts et même images en base64 — dans un unique fichier HTML. C’est proche de l’EPUB, un peu lourd et laid, mais avec un peu d’attention ça fonctionne, et le navigateur peut l’ouvrir naturellement
En revanche, l’utilisateur n’a aucun moyen de savoir qu’il peut « télécharger cette page web et la conserver hors ligne ». Ce serait bien d’avoir une extension comme
.htmlsindiquant qu’il s’agit d’un HTML sans ressource externeJe ne vois pas pourquoi les navigateurs ne pourraient pas faire la même chose pour l’EPUB. Il existe déjà des extensions de navigateur qui font exactement cela. La question est de savoir si le format EPUB gagnera en popularité
Puis on a eu « besoin » de designs et de mises en page façon magazine, mais comme cela restait centré sur le document, c’était encore assez correct
Ensuite, on a essayé de forcer HTML à devenir une plateforme de distribution d’applications. Les layouts CSS actuels se sont enfin rapprochés des moteurs de mise en page d’applications traditionnels
À mon avis, les vingt dernières années ont été en grande partie gaspillées faute d’un bon mode de distribution d’applications multiplateforme. À l’exception de Java
Pour que ce format se comporte de manière reproductible partout, il doit être standardisé et il doit être facile d’implémenter de nouveaux moteurs de rendu. S’appuyer sur des webviews ne me paraît pas être la voie à suivre
La beauté du PDF tient au fait qu’il est très fiable. Un PDF d’il y a dix ans se rend aujourd’hui exactement comme avant
Pour que cet effort réussisse, il faudrait sans doute réduire fortement le périmètre des documents. Le sous-ensemble XHTML autorisé devrait être très limité, et la priorité devrait être la capacité à obtenir le même rendu partout. D’abord une mise en page fixe avec taille de page fixe, puis seulement des documents reflowables. Il faudrait aussi une norme incluant des documents de test complets et leurs sorties de rendu
En l’absence de prise en charge par les navigateurs, il ne serait pas très difficile d’écrire un proxy côté serveur qui transforme un EPUB en site navigable, avec des contrôles de changement de chapitre et quelques options simples de mise en page
Bien sûr, pour lire la plupart des livres numériques commerciaux via un tel proxy, la prise en charge du DRM nécessaire risquerait d’être très problématique juridiquement
À bien y réfléchir, la prise en charge par les navigateurs des EPUB avec DRM approuvés par les éditeurs ne serait techniquement qu’à un demi-pas de la prise en charge du DRM pour les pages web ordinaires, ce qui est une perspective assez effrayante
Je considère le PDF comme un terrible format legacy, avec une complexité inutile. La plupart des usages du PDF n’ayant rien à voir avec l’impression, la logique de composition ne me parle pas
Dans la grande majorité des cas, il est bien plus important que ce soit facile à lire sur téléphone, tablette et ordinateur
L’auteur disait qu’iBooks ne prenait pas en charge l’affichage en défilement, ce qui m’a surpris, alors j’ai vérifié. iBooks sur macOS ne prend pas en charge le défilement des fichiers ePub, mais iOS et iPadOS le prennent en charge. C’est une décision très étrange de la part d’Apple
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Je n’ai jamais vu de documentation technique distribuée dans un format autre que PDF qui soit agréable à lire et à rechercher. Même sur téléphone
Je ne veux pas de documents dont l’apparence change en fonction d’un état temporaire comme l’appareil de lecture ou la taille de la fenêtre. Je veux un document à mise en page fixe, bien conçu par son auteur
Même pour lire sur un petit écran ou dans une petite fenêtre, si ce n’est pas un simple document texte, je veux un lecteur intelligent avec zoom et déplacement rapides, plutôt qu’un changement de mise en page. Il ne doit pas avoir de comportements stupides comme certains lecteurs Android où le défilement vertical ou Page Up/Page Down déplacent aussi la position horizontale, rendant les colonnes de texte difficiles à lire
Le simple respect des recommandations traditionnelles sur la largeur maximale des colonnes de texte suffit à rendre la lecture confortable sur téléphone. La lecture sur téléphone ne devient pénible que lorsque l’auteur crée des colonnes beaucoup trop larges et enfreint les règles typographiques traditionnelles
C’est pourquoi essayer de créer un standard unique adapté à tout me semble être une mauvaise idée. Pour les documents numériques, deux standards vaudraient mieux. L’un serait un format avec multimédia complet et interactions, sauf le réseau ; l’autre serait un sous-ensemble limité au noir et blanc, sans multimédia, avec des interactions essentiellement restreintes aux hyperliens internes au document
Et nous avons déjà presque ces deux formats : HTML, MHTML=EML, et EPUB
Bien sûr, il faut aussi un troisième format pour l’archivage physique et les rares documents numériques à mise en page fixe, rôle que PDF/A semble déjà plutôt bien remplir
Le SVG multipage serait peut-être possible, mais pour imprimer correctement plusieurs pages, il faudrait probablement finir par exporter d’abord en PDF. Je dis cela en pensant à Inkscape
Il y a 8 jours, il y avait eu « Portable Web Documents – An Alternative to PDF Based on HTML5 (2019) », qui avait obtenu 134 points
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
Je me demande ce qu’un lecteur EPUB apporte qu’un navigateur n’a pas. À première vue, il n’y a qu’une seule réponse, assez mineure : les fichiers .epub, c’est-à-dire la possibilité de traiter des fichiers zip comme des répertoires
Si c’est vraiment la seule différence entre un lecteur EPUB et un sous-ensemble de navigateur, l’approche la plus simple et la moins coûteuse serait la suivante
Faire en sorte que les navigateurs existants traitent, sous certaines conditions, les fichiers zip comme des répertoires
Définir une restriction HTML vérifiable mécaniquement qui garantisse les ressources entièrement locales mentionnées dans l’article original. Exiger que toutes les URL, sauf les liens, soient des chemins relatifs pourrait suffire
Déclarer les fichiers zip qui respectent cette restriction comme des « EPUB portables »
Oublier tous les lecteurs EPUB dédiés, existants ou nouveaux
Pour les ressources entièrement locales, j’aimerais voir une exigence selon laquelle chaque objet doit disposer d’une solution de repli disponible localement. Par exemple, utiliser une police standard si la police en question ne peut pas être récupérée. Ce ne sera pas parfait visuellement, mais si l’on reste dans les limites prévues pour les solutions de repli, cela devrait fonctionner raisonnablement
Il reste un mode de défaillance qui n’a pas encore été suffisamment traité : les images qui ne fonctionnent pas correctement. Fondamentalement, les images ne se redistribuent pas avec le texte. On peut en résoudre une bonne partie avec du SVG, mais pas quand il s’agit de vraies images raster. Au final, il faudra probablement fournir plusieurs résolutions
J’ai aussi rencontré un problème lié, sans encore voir de bonne réponse : un SVG conscient de la résolution, qui charge une image plus détaillée lorsqu’une résolution suffisante est disponible. Si l’on trace des lignes sous-pixel, elles deviennent floues, mais si l’on agrandit la même image, ces lignes deviennent utiles. Les icônes Windows reconnaissent ce problème en pouvant inclure plusieurs résolutions et utiliser celle qui convient au contexte
L’auteur est postdoctorant sous la direction de Shriram Krishnamurthi. Shriram Krishnamurthi est l’auteur de Programming Languages: Application and Interpretation(PLAI) et l’un des auteurs de Data-Centric Introduction to Computing(DCIC)
Je suis en train de lire PLAI et DCIC, et je suis vraiment impressionné par le soin minutieux que les auteurs ont apporté pour en faire des œuvres d’art pédagogiques. C’est une vraie marque d’affection
https://willcrichton.net/
https://rust-book.cs.brown.edu/
Les PDF peuvent inclure des polices, mais ils ne le font souvent pas et s’appuient sur les polices du système. L’une des raisons est que l’intégration de polices dans un PDF peut fortement augmenter la taille du fichier. Dans certains cas, une seule police peut être plus volumineuse que tout le reste du fichier
J’ai déjà implémenté l’incorporation de polices dans un logiciel qui générait des PDF, et trouver comment la faire fonctionner de manière fiable s’est révélé étonnamment difficile
Le rendu cohérent des PDF n’est pas non plus aussi garanti qu’on le pense. J’ai vu plusieurs cas où le même PDF était rendu différemment selon le lecteur PDF utilisé. En général, les différences sont subtiles, mais il existe parfois des cas limites où elles sont assez importantes. J’ai même vu la même version d’Acrobat Reader rendre un PDF différemment selon le système d’exploitation
Ainsi, avec des polices système compatibles, la mise en page du document rendu ne devrait pas changer. Bien sûr, il existe des cas de polices système présentées comme compatibles en métriques avec les anciennes polices Adobe PostScript, tout en présentant de subtiles différences
Hormis le petit nombre de polices système standard, les documents PDF incluent généralement non pas toute la police, mais seulement le sous-ensemble de glyphes correspondant aux caractères effectivement utilisés dans le texte
C’était un The Daily WTF du quotidien