URL: https://linuxfr.org/users/liorel/journaux/de-l-affichage-des-documents Title: De l'affichage des documents Authors: Liorel Date: 2021年04月02日T12:01:55+02:00 License: CC By-SA Tags: firefox, markdown, word, libreoffice et pdf Score: 13 Bonjour Nal, Si tu vis sur le même fuseau horaire que moi, aujourd'hui c'est vendredi, et vendredi c'est le jour ~~du reconfinement~~ des journaux qui dénoncent grave. # Le problème Ma thèse est la suivante : Word, LibreOffice Writer, Adobe Acrobat Reader ainsi que tous les lecteurs PDF sont de bons gestionnaires d'impression, mais en termes d'affichage de documents, ils sont catastrophiques[^1]. Quelles en sont les raisons ? * Ils raisonnent par pages, ce qui est adapté au papier, beaucoup moins à l'écran : * Une page a un en-tête, un pied de page et des marges trop petites pour contenir la démonstration du dernier théorème de Fermat, mais qui cassent quand même le rythme de la lecture * Le comportement par défaut d'Adobe Acrobat est même de forcer la lecture page par page en empêchant de scroller jusqu'à ce que la transition de page soit intégralement franchie, cassant encore plus le rythme ! Adobe est tellement persuadé de la pertinence de ce comportement que l'interface par défaut ne contient pas de bouton pour le modifier en un clic. * La numérotation des pages écrite sur le document n'a aucune raison de suivre la numérotation des pages du fichier informatique, ce qui fait que quand on veut d'emblée sauter au chapitre sur le théorème de Gibbard-Satterthwaite qui se trouve en page 34, on se retrouve en page 32 en plein milieu d'une discussion sur le jugement majoritaire, méthode de scrutin qui ne présente aucun intérêt. Ben oui, la table des matières n'est pas numérotée sur le papier, mais elle l'est dans le fichier informatique * Ils ont des marges latérales fixes. Ceci ne pose aucun problème sur papier, mais à l'écran, c'est soit insuffisant pour un affichage sur écran large (qui est quasiment standard de nos jours sur PC), ce qui aboutit à n'afficher qu'un nombre réduit de lignes et à être obligé de dézoomer ou de scroller sans arrêt, soit excessif pour un écran de smartphone, ce qui oblige à zoomer et ajoute un défilement latéral inutile (il ne sert qu'à afficher des marges) et gênant pour la lecture. * 9 fois sur 10, les liens sont non cliquables parce que la conversion en PDF a été faite n'importe comment. [^1]: Il en découle que même $\LaTeX$ est un producteur de documents principalement destinés à l'impression, pas à la lecture sur écran. # Il existe une solution Il existe des logiciels qui ont été optimisés, depuis des années, principalement autour de la tâche d'afficher des documents sur écran. La contrepartie étant que ce sont d'assez mauvais gestionnaires d'impression. Ils ont pour nom Firefox, Chrome, et dans une moindre mesure, IE/Edge (pour ce dernier, on se demande vraiment dans quel but il est optimisé). Les documents HTML sont conçus principalement pour l'affichage sur écran et les navigateurs sont optimisés pour un rendu de qualité sur tout type de matériel, au prix d'un rendu variable. Il n'y a ni marges latérales fixes, ni scrolling latéral inutile (normalement), et les liens sont cliquables. Bien entendu, ils font abstraction de la notion de page qui n'a de sens que sur papier. ## Pourquoi la solution n'est-elle pas utilisée plus largement ? Là, Nal, j'en suis réduit à formuler des hypothèses. La plus évidente est qu'il n'existe pas de bon logiciel capable de générer du HTML. Mais je pense que c'est prendre le problème à l'envers. Il n'existe pas de bon logiciel capable de générer du HTML en WYSIWYG parce que, justement, le rendu est variable et que la séparation du fond et de la forme est imposée. Pour toi, moule dotée de capacités d'abstraction élevées, la séparation du fond et de la forme est une évidence. Mais pour bon nombre de personnes, il est très difficile de rédiger un document sans le voir prendre forme au fur et à mesure. ## Vers une sortie de crise J'ai récemment pris l'initiative d'utiliser Markdown plutôt que Word/LibreOffice pour rédiger un compte-rendu d'analyse au boulot et le convertir en HTML. La réception a été assez positive, surtout du fait que ça m'a permis de produire un résultat dans le temps qu'il faut pour attaquer le problème plutôt que dans le temps nécessaire à attaquer le problème + mettre en page proprement (quant à moi, j'aime beaucoup $\LaTeX,ドル mais faire la mise en page en Word est une punition que je ne souhaite même pas à mon pire ennemi). Pour un rapport court, qui sera lu par une poignée de personnes, c'est rentable. Markdown fournit un bon intermédiaire : Il existe une mise en page minimaliste, c'est lisible par un non-technicien sans se faire peur avec des balises de partout, et si vraiment on te demande du Word ou du PDF, la conversion est triviale avec Pandoc.

AltStyle によって変換されたページ (->オリジナル) /