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 catastrophiques1. 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.
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 
, 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.
-
Il en découle que même
est un producteur de documents principalement destinés à l'impression, pas à la lecture sur écran. ↩
# Du paramétrage de l'affichage
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 02 avril 2021 à 12:56.
L'affichage ça se paramètre dans LibreOffice (dans Word aussi d'ailleurs) -> Affichage Web.
Avec Okular et d'autres lecteurs de pdf -> Affichage continu.
Le nom, web, continu, peut varier selon les logiciels.
Mieux dans LibreOffice quand on exporte en pdf en passant par Exporter au format PDF, on affiche les options, on peut, dans l'onglet
Vue initialecocher la caseContinuetout en gardant, évidemment, le sommaire. Et en plus, comme la maison ne se refuse rien on peut personnaliser les barres d'outils et remplacer le bouton PDF par défaut par le second qui ouvre les options (ce que j'ai fait d'ailleurs).Concernant la mise en page, concevoir un modèle adapté, ensuite, ben faire ses documents à partir de ça. On gagne du temps, beaucoup.
Mais ça fait moins de gymnastique.
Cela dit, l'utilisation des modèles, dans LibreOffice, permet, pour un même document de l'avoir en version pdf imprimable, pdf pas à imprimer et epub notamment. Ça génère, évidemment, trois fichiers.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Du paramétrage de l'affichage
Posté par Jean-Baptiste Faure . Évalué à 2. Dernière modification le 02 avril 2021 à 16:46.
Personnellement je préfère au mode web un affichage par page qui ne montre pas le découpage en pages.
Dans LibreOffice :
- mettre les marges à 1 mm dans le style de page ;
- masquer les espaces entre les pages : quand le pointeur se trouve entre 2 pages il prend la forme d'un rectangle avec une flèche au dessus et une en dessous qui pointent sur le rectangle comme pour le réduire, il suffit alors de double-cliquer pour faire disparaître l'espace entre les zones de texte des pages.
- choisir le niveau de zoom "largeur de page".
À la différence de l'affichage web, cette façon de faire conserve la largeur de page, il n'y a que la hauteur de page qui disparaît.
# concernant le PDF
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 7.
Le PDF est un format extrêmement complexe, j'avais même une difficulté monstre à couper une double page en deux.
Un PDF est un container raisonnée par page. Et dedans, tu peux avoir le texte sur une bonne quinzaine de formats différents, allant du HTML embarqué, au RTF jusqu'à l'applat au format jpg.
En gros, le PDF a réellement été conçu comme description de pages, et il est difficile de raccrocher le texte de pages entre eux, puisque des fois la notion de colonne de chemin de fer peut ne pas être là, et les lettres dispersées indépendamment.
D'ailleurs, même les logiciels commerciaux d'accessibilité du desktop ont un mal terrible à se dépatouiller d'un PDF.
Conseil : si vous générez un PDF, ayez vraiment des notions solides de composition PAO pour vérifier que celles-ci soient bien exportées . Oui, on peut faire du PDFa 1.4 et être complètement crâde et pondre un document qui demande à être re-OCR-isé pour être lisible. Terrifiant pour un PDF issu d'un outil de composition de texte.
[^] # Re: concernant le PDF
Posté par _kaos_ . Évalué à 2.
Salut,
Et jusqu'à du son en mode "embeded" (pour de la vidéo, j'ai cherché, mais pas longtemps, et pas trouvé ce que je souhaitais) ;)
Matricule 23415
[^] # Re: concernant le PDF
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4. Dernière modification le 02 avril 2021 à 14:54.
Du coup, quand on génère un pdf, autant avoir bien conscience qu’il s’agit d’un format de document destiné à faire bonne impression et pas autre chose ; quitte à y adjoindre ses sources latex (ou xml, ou…) pour éviter à celui qui recevra de passer par la case OCR, et autres manipulations saugrenues. Ça tombe bien, il est justement possible d’incorporer n’importe quel fichier dans un pdf. Latex fait ça très bien. Il faudrait peut être ajouter cette option dans LibreOffice. C’est fort pratique.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: concernant le PDF
Posté par Jean-Baptiste Faure . Évalué à 9. Dernière modification le 02 avril 2021 à 16:07.
Ça existe depuis longtemps dans LibreOffice, c'est le PDF hybride. Dans le dialogue d'export PDF 1ère case à cocher en haut à droite du premier onglet.
[^] # Re: concernant le PDF
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 02 avril 2021 à 16:19.
OpenOffice faisait déjà ça :-)
En fait ce qui serait une réelle amélioration c'est que le bouton de la barre d'outils ne soit pas l'export PDF direct mais bien celui Exporter en PDF qui ouvre la boite de dialogue et permet de voir les options. Ce n'est pas la première fois que je constate que les personnes ne vont tout simplement pas essayer de voir plus que le bouton en la matière.
Et la fonctionnalité pdf hybride génère, logiquement, un fichier deux fois plus lourd, ce qui n'est pas toujours souhaitable.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: concernant le PDF
Posté par jben . Évalué à 4.
C'est un problème que j'ai eu récemment, comment splitter une page en deux.
J'ai écrit un truc à l'arrache pour ça.
# Transport
Posté par claudex . Évalué à 7.
Il n'existe surtout pas de moyen de transférer des documents HTML (et surtout les composants à côté, comme les images) facilement et qui fonctionnerait (presque) partout. On manque d'un format "Web archive" qui soit supporté un peu partout.
(Il existe des formats dans ce but, mais aucun n'est supporté un peu partout)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Transport
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Oui l'archivage est une grosse problématique et le html, c'est le zouk… par exemple, tout n'est pas dans le même fichier. La visualisation évolue pas mal avec les navigateurs… voir avec le même navigateur au cour du temps.
Un PDF généré il y a 25 ans se lit et s'imprime toujours pareil de nos jours.
[^] # Re: Transport
Posté par BFG . Évalué à 4.
Pourtant, les relevés de ma banque au format PDF ont un rendu différent selon le lecteur utilisé (par exemple avec Okular ou Evince).
[^] # Re: Transport
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 02 avril 2021 à 14:09.
Cela peut dépendre des polices. En effet, si le document a été généré avec une police qu'on n'a pas et dans certaines conditions, le lecteur de pdf va essayer de rendre au mieux la police et là, ça dépend du lecteur, du coup, le rendu sera différent.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Transport
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 5.
ça veut dire qu'ils ne sont pas au format PDFa, c'est à dire qu'ils n'incluent pas tous les éléments nécessaires à leur reproduction.
De la part de ta banque, cela veut dire qu'elle peut ne pas être conforme.
C'est très fréquent sur les outils de génération auto, car il faut alors songer à activer les options et joindre les fichiers dans la ligne de commande
[^] # Re: Transport
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 02 avril 2021 à 14:10.
On peut très bien générer un fichier unique HTML qui contient tout "inline" :
- le texte bien évidemment
- le CSS pour la mise en page
- même du Javascript si ça te chante
- et les images également : le standard HTML accepte les images en base64
EDIT : sinon il y a le ePUB qui est pas trop mal dans le style "orienté texte" au lieu de "orienté page"
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7. Dernière modification le 02 avril 2021 à 14:25.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Transport
Posté par monsieurw . Évalué à 2.
A propos des ressources embarquées en base64 en HTML5, on peut aussi y mettre des fichiers audio ou vidéo ou une favicon.
Cela dit, il faut que le navigateur qui lit la page ait le bon codec pour les lire.
Ce n'est pas forcément recommandé, mais c'est possible :-)
--
MonsieurW
[^] # Re: Transport
Posté par claudex . Évalué à 6.
Qui seront complexe à télécharger (je crois que les browser vont vouloir les lire tout de suite au lieu d'afficher le lien de téléchargement, pareil dans certain clients mails qui vont vouloir aussi l'afficher inline avec toutes les limitations d'un client mail pour l'interprêtation du html.
Il me semble qu'il y a des limitations à 32k dans certains navigateurs.
Oui, c'est ce que je disais, il y a plein de format mais aucun assez répendu pour qu'on puisse envoyer un fichier dans ce format et être assez confiant que la personne en face va pouvoir le lire.
Et au final, il manque un html.gz pour avoir un truc pas gros qui inclut tout.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Transport
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Quand tu enregistres une page dans un brouteur, il sauvegarde un fichier html et ressources dans un sous dossier. Un petit coup de
apack mapage.zip mapage.html mapageet hop.Sinon il y a déjà des formats qui existent comme MHTML ou WARC.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Transport
Posté par claudex . Évalué à 3.
C'est un peu ce que je dis dans mon premier commentaire…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Transport
Posté par EmmanuelP . Évalué à 4. Dernière modification le 03 avril 2021 à 07:42.
Pour le coup, epub, c'est quand même pas mal répandu, c'est un format accepté par pas mal (toutes ?) de liseuses, et il y a des lecteurs pour tous les OS.
Sous linux, je recommande Foliate, qui a une interface très agréable, qui rend la lecture de livres sur un ordi presque supportable:
https://johnfactotum.github.io/foliate/
[^] # Re: Transport
Posté par claudex . Évalué à 4.
Pas les kindle, ça en fait une grosse partie.
La question n'est pas "est-ce que c'est possible de lire ce format" mais "si j'envoie dans ce format, est-ce qu'il y a de grande chance que mon interlocuteur puisse le lire facilement".
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Transport
Posté par barmic 🦦 . Évalué à 2.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Oui, il y les xml.zip de l'OASIS, alias
.odt“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 3.
Autant je connais plein d’éditeurs pour le format
.odt, autant je n’ai aucune idée de comment en visualiser un sans sortir une usine à gaz.[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
J'ai tapé « odt viewer » dans un certain moteur de recherche ; voici ce que j'ai retenu de la première page (pas dans l'ordre)
Du coup, par rapport à mon mode de fonctionnement, j'ai ajouté alternativement « cli » et « console » comme troisième mot de la recherche
antiwordetwvappeléodf2txt\o/présenté sur https://www.cnx-software.com/2015/04/01/how-to-read-openoffice-libreoffice-files-from-the-command-line/unoconvouabiwordsont installés, on peut en extraire le texte. Dans le même esprit, https://www.systutorials.com/3-ways-of-odt-to-txt-file-conversion-in-command-line-in-linux/ indique qu'on peut utiliserlibreofficeoupandoco3readqui devrait pouvoir s'utiliser aussi même si le format a pas mal évolué“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 2.
J’ai regardé un à un les différents liens que tu proposes, et aucun de ces logiciels n’est adapté à visualiser des .odt sur Linux.
Sauf via un navigateur Web, mais là on revient aux usines à gaz que j’évoquais dans mon message précédent.
[^] # Re: Transport
Posté par Jean-Baptiste Faure . Évalué à 4. Dernière modification le 04 avril 2021 à 16:56.
Peux-tu définir ce que tu appelles « usine à gaz » ?
S'il s'agit juste d'une allégorie mal choisie pour « logiciel qui pèse plusieurs dizaines de Mo », qu'est-ce qu'il y a de choquant à avoir besoin de tout ça pour afficher un document dont la structure peut être complexe sur des supports physiques de taille variable et fonctionnant sur des OS multiples ?
Cela signifie juste que quand on dit « je veux simplement afficher ce document » simplement s'applique à vouloir et non à afficher : le souhait est simple mais sa réalisation est complexe. Cela arrive tous les jours dans plein de domaines, c'est la vie, il ne faut pas en faire un drame.
[^] # Re: Transport
Posté par barmic 🦦 . Évalué à 4.
Je pense que l'on peut considérer comme usine à gaz une solution qui consiste à prendre un format ultra complexe, l'interpréter avec des outils tout aussi complexes qui vont le mapper sur un autre format qui n'a rien de trivial pour ensuite lui faire calculer son rendu par un nouveau logiciel toujours aussi complexe.
Parce que oui prendre un odt le transformer en html/css/js pour le rendre c'est architecturalement très complexe.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Transport
Posté par Jean-Baptiste Faure . Évalué à 1.
Et qui fait ça ?
[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
De la description, il s'agit des solutions de visualisation en ligne : au final ça génère un affichage dans une page web quoi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Transport
Posté par barmic 🦦 . Évalué à 3.
Tu réponds à :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 2.
En effet, j’aurais dû commencer par ça ;)
Ici je désigne par « usine à gaz » un logiciel qui a beaucoup de fonctionnalités superflues par rapport à l’action demandée. Ce sera par exemple le cas de Firefox, qui permet d’interpréter du JavaScript ou de télécharger des ressources distantes, tout comme celui de LibreOffice, qui permet d’éditer le document ou de le convertir dans divers format.
Le souci de ces logiciels est en partie sur la consommation inutile de ressources, mais surtout ils vont généralement proposer une interface surchargée et incluent potentiellement beaucoup plus de bugs qu’une application dédiée à une action simple.
[^] # Re: Transport
Posté par Jean-Baptiste Faure . Évalué à 4.
Selon ta définition, je ne vois pas de logiciel qui ne soit pas une usine à gaz. Même des outils emblématiques comme vim, emacs, tous les IDE, les éditeurs Latex, tous les éditeurs de texte avec leurs multiples plugins, tous les éditeurs d'images et les logiciels de dessin, tous ces logiciels permettent chacun de faire de multiples choses, tous sont des usines à gaz selon ta définition. Et même des logiciels en ligne de commande comme ffmpeg avec des millions d'options rentrent aussi dans ta définition. Du coup je ne la trouve pas vraiment opérante.
Et donc je retourne ma question : peux-tu donner des exemples de logiciels dédiés à une action simple ?
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 3.
En voici quelques uns qui me semblent coller à la définition que je donne, et font partie de mes logiciels du quotidien :
Par contre ffmpeg n’entre pas dans ma définition d’usine à gaz, parce que malgré sa quantité impressionnante d’options il ne sert bien (à ma connaissance) qu’à une seule tâche simple : convertir des fichiers audio/vidéo d’un format à un autre.
Et une même application peut être ou non une usine à gaz selon la manière dont on l’utilise ;) Par exemple Gimp est une usine à gaz si on l’utilise pour visualiser des images ou lire des PDF, mais pas si on l’utilise pour éditer des images. De la même manière que LibreOffice est une usine à gaz pour lire des fichier .odt, mais pas pour les rédiger ou les modifier.
Bref, tout est une question de contexte.
[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Salut
:-)Désolé, ma réponse n'était pas bien formulée
:-/Je ne prétendais pas apporter LA réponse ; c'est juste que la question m'a interpelée et que je me suis demandé ce que donnerait une recherche rapide sur le web (ce qui est plus une façon de procéder windozienne car le premier réflexe pour les usagers des distributions standards devraient être de rechercher dans la logithèque directement…) Ceci a permis de se rendre compte qu'effectivement, on peut lire ce format sans avoir d'éditeur sur les deux plateformes dominantes de smartphones (donc c'est possible pour le commun des mortels, ta question ne ciblant pas initialement les linuxiens) ou via un site web (ce qui cadre bien avec l'usage actuel du tout en ligne et reste une alternative pour les autres plateformes)La seconde partie de ma réponse montre qu'il existe des solutions bien linuxiennes pour les gens travaillant en ligne de commande : odt2txt, pandoc, o3read, et certainement d'autres.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 2. Dernière modification le 04 avril 2021 à 20:57.
Pas de souci, ma question initiale ne l’est probablement pas non plus ;P
Ce sont justement les outils que je connais déjà, mais toujours pas ce que je cherche. On peut avec ces outils extraire des informations des documents, mais pas les lire en conservant le format pensé par la personne les ayant rédigés (couleurs, polices, mise en forme, etc.).
Ce que j’ai en tête, et qui correspond peut-être aux solutions Web/mobile que tu as trouvées (je ne les ai pas testées), c’est quelque chose de similaire à ce qui se fait pour le PDF : un outil dédié à la lecture sur écran. Mais qui contrairement aux lecteurs de PDF ne se baserait pas sur une notion de page, héritée de l’impression sur papier.
[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ah oui…
:-)À vérifier, mais je crois que les lecteurs classiques Evince/Okular/etc. avent lire aussi ces formats moyennant quelque extension ou configuration (mais dans ce cas, je pense que ça se basera sur la présence des suites bureautiques pour récupérer la vue du document formaté) ; il me semble que l'aperçu de MacOS fait ainsi (juste pour la comparaison hein, tu as bien indiqué que tu es intéressé que par la plateforme Linux)Par contre, il me semble difficile et impertinent de vouloir à tout prix éviter la notion de page avec des documents/formats pensés par rapport à l'impression (même si la majorité des visualiseurs, y compris pour le PDF, permettent le « mode continu » par opposition au « mode paginé » et ça marche bien tant qu'il n'y a pas de renvois/références vers/à des numéros de pages etc.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 2.
En temps normal je serais peut-être d’accord avec ça, mais là c’est le thème du journal auquel on répond ;P
[^] # Re: Transport
Posté par Jean-Baptiste Faure . Évalué à 3. Dernière modification le 04 avril 2021 à 22:07.
Il faudrait déjà que les utilisateurs prennent la peine de penser leurs documents pour la lecture sur écran. Même avec des outils comme LibreOffice on peut s'affranchir de tout ce que la segmentation en pages fait perdre de confort lors de la lecture sur écran. Et l'utilisation de modèles permet de transformer aisément un document organisé pour la lecture sur écran en document imprimable et vice versa.
Cela dit, même sur écran la notion de page a une grande utilité parce qu'elle permet de se repérer dans le volume du document, de façon bien plus parlante que le pourcentage de texte qu'indiquent les lecteurs de textes numériques des liseuses. Retrouver un morceau de texte dans un bouquin c'est difficile quand on ne peut pas s'aider de la mémoire visuelle de la page. Des indices du genre "c'était vers le milieu du 2e chapitre dans la première moitié d'une page gauche" deviennent complètement inopérants.
[^] # Re: Transport
Posté par barmic 🦦 . Évalué à 2.
La notion classique de page est limitante pour ça. Pourquoi toutes les pages devraient représenter une même surface ? Pourquoi devraient-elles être dans un ratio prédéfini ? Les seuls raisons à cela sont l'impression et la force de l'habitude. S'en affranchir permet à la fois d'être plus souple et/ou plus créatif (par exemple découper les pages en fonction de leur contenu) et simplifie la vie au lecteur (il n'y a qu'à voir pdf vs epub sur liseuse).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Transport
Posté par Pinaraf . Évalué à 3.
Alors il faut absolument que je sorte une nouvelle version de Calligra, les versions ≤3.2 sont inutilisables pour ça, mais on a un plugin Okular qui permet de faire de ce dernier Okular un afficheur odt et odp…
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 2.
J’étais justement tombé dessus en fouillant les dépôts de ma Debian, et c’est en ne trouvant que cet unique plugin qui semble répondre à ma recherche que j’ai posté le message auquel tu réponds ;)
Après c’est peut-être juste une question d’options de compilation spécifiques à Debian, mais une simulation d’installation sur une Debian Buster sans KDE de
okular+okular-backend-odtm’annonce l’installation de 299 (!) nouveaux paquets et de l’utilisation de ~400Mio (!!) d’espace disque. Je dois admettre que pour un "bête" lecteur de document, ça pique un peu.On en revient donc à la question des usines à gaz, terme que j’explicite un peu plus haut.
[^] # Re: Transport
Posté par Pinaraf . Évalué à 3.
Il faudrait regarder le détail des paquets qui justifie la consommation des 400Mio, ça me surprend un peu aussi.
Par contre le nombre de paquet est assez logique quand tu cherches justement à faire des logiciels plus légers. Lors du passage de kdelibs4 à KDE Frameworks 5, tout a été découpé en plein de morceaux réutilisables.
Après… comment comptabiliser l'espace utilisé par un logiciel ? Quand on prend une application Windows ou MacOS, on ne compte pas le poids des bibliothèques système dans le poids de l'application… Quand on installe une application GNOME et qu'on utilise ce dernier, on ne voit pas le poids des bibliothèques GNOME utilisées… Et de même pour une application KDE…
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 3.
J’ai vu passer entre autres VLC comme dépendance de Phonon, qui est si je ne me plante pas le système de gestion du son de KDE. Il doit y avoir pas mal d’autres machins dans ce style qui arrivent par le jeu des dépandances, et qui ne se verraient pas sur un environnement KDE.
Et ça correspond exactement aux critiques que je fais à ces logiciels : pourquoi je me retrouve à devoir installer un lecteur audio pour visualiser des documents .odt ? Lecteur audio qui même si je ne l’utilise pas va ensuite devoir être maintenu à jour, et est une excellente source de nouveaux bugs.
Bon, en réalité je sais comment demander explicitement à apt de m’installer un faux backend Phonon pour ne pas tirer VLC par dépendance. Mais c’est ce qui se passe avec une installation "naïve" si on se contente d’un
apt install okular okular-backend-odt.Et ce souci avec VLC se reproduit avec d’autres dépendances, qui vont donc m’amener un serveur de gestion d’imprimantes (CUPS), un système de correction orthographique (aspell), des nouvelles collections de fontes, un éditeur de marque-pages (KEditBookMarks)… On arrive vite à 400 Mio ;)
[^] # Re: Transport
Posté par Pinaraf . Évalué à 4.
Parce qu'un document peut embarquer du contenu multimédia… Et au passage c'est un choix de Debian, tu pourrais avoir 'juste' gstreamer comme dépendance.
Tu ne veux pas pouvoir imprimer le document ?
Même quand on affiche un document, on peut saisir des formulaires, et donc vouloir la correction orthographique
Ben là c'est normal, surtout qu'un .odt n'embarque pas les polices de caractères…
Ça c'est un choix de debian
Et là je ne te comprends pas. Si ton but c'est d'avoir le système le plus minimaliste possible, surtout sur l'espace disque, pourquoi utilises-tu une distribution généraliste qui au contraire va vouloir satisfaire un maximum de personnes ? Tu ne veux pas d'impression ni de correction orthographique, ok (ce sont des dépendances optionnelles), mais penses-tu que c'est le cas de la majorité des utilisateurs ?
Au passage, vu les dépendances que tu cites, tu ne serais pas avec la configuration par défaut qui en sus des dépendances va installer les recommandations ?
[^] # Re: Transport
Posté par vv222 (site web personnel) . Évalué à 2.
C’est bien pour éviter tout ça que je demande depuis le début un visualiseur de documents. Pas pour l’imprimer. Pas pour le modifier. Juste pour le lire.
Autant qu’il n’y ait pas d’application adaptée, je peux l’admettre. Il y a peut-être très peu de personnes qui cherchent à lire des .odt sur écran.
Mais que vous soyez plusieurs à ne pas comprendre le concept, ça me dépasse.
On en revient donc encore à la question de l’usine à gaz. Ce qui est apparemment aussi le modèle choisi par Okular.
Pour ma part je m’arrête ici sur le sujet des applications pour travailler avec des fichiers OpenDocument, ça commence à vraiment tourner en rond ;)
S’il y a une information que je vais retenir de ce fil de discussion, c’est que ce format n’est tout simplement pas prévu pour la lecture sur écran.
[^] # Re: Transport
Posté par Pinaraf . Évalué à 2.
Peut-être que tu n'admets pas le concept qu'un lecteur de PDF qui ne gère pas les formulaires soit inacceptable pour 99,99% des gens.
Peut-être que tu n'admets pas le concept qu'un lecteur de documents qui ne gère pas l'impression soit inacceptable pour 99,99% des gens.
Et pour autant, tu noteras que personne ne te juge, alors que tu te permets des qualificatifs blessants pour le travail des développeurs, de surcroît le tout basé sur la configuration de ta distribution qui par défaut ne va pas aller dans ton sens et ajouter de nombreuses dépendances inutiles (je suis allé vérifier, pour avoir eu ces dépendances à l'installation d'Okular, ta Debian n'est définitivement pas configurée pour une installation légère).
Et je tiens à préciser que l'ajout de l'impression dans un «visualiseur» de documents, ça sera quelques kB de code. Mais pardon, c'est une usine à gaz, méchants développeurs…
[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Si, si, on t'a tous compris
:-)chacun un peu à sa façon…Moi par exemple, je suis resté dans un sens très basic de viewer qui veut que le « contenu » puisse être restitué sur mon média, purement textuel (console/terminal, imprimante matricielle, etc.), comme je le fait déjà avec les pages web (via Lynx et similaires.)
Tu aurais voulu quelque chose de plus, comme le ferait ton Firefox/Chromium/etc, pour une page web, avec tout le bling autour du contenu. Un peu comme une photo. D'autres l'ont compris ainsi aussi je crois.
Mais en dehors de la restitution par le visualiseur, tu voudrais aussi supprimer la pagination pour être dans l'esprit du journal… Au contraire je ne suis pas choqué par cela parce-que mes visualiseuses reformatent pour paginer par rapport à l'écran (au final la navigation se fait dans un pager intégré ou externe, juste que ce ne sont pas des pages du format papier mais des pages écran) Les outils graphiques proposent quelque chose qui se rapproche de ton besoin, le « défilement continu », qui peut prendre plusieurs noms et qui n'est pas actif par défaut.
L'autre point enfin, est que pour toi, le viewer doit juste faire un affichage photo… Tandis que beaucoup d'autres usagers veulent, en plus de cet « aperçu », pouvoir sélectionner et copier des morceaux de texte, imprimer tout ou partie du document, grossir ou réduire proportionnellement l'ensemble, etc. Oui, la notion de visualisation simple n'est pas si simple (en tout cas n'a pas une définition qui semble commune si ce n'est qu'on ne peut pas modifier le document… ce qui n'exclut pas l'usage des usines à gaz en lecture seule…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Transport
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 05 avril 2021 à 23:52.
Que je sache cela demande de modifier le document. Il me semble qu'un odt n'est pas fait pour être lu, mais pour pour générer un document. Généralement soit un PDF soit une impression physique et que ça teinte son écosystème. Il n'y a pas de possibilité de responsive avec OpenDocuement pour parler de ce dont tu parle.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
cf. ci et là entre autres, pour ce à quoi je faisais allusion.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Transport
Posté par EmmanuelP . Évalué à 5.
SingleFile est une extension firefox qui permet de faire une sauvegarde d'une page web dans un seul fichier en un seul clic:
https://addons.mozilla.org/fr/firefox/addon/single-file/
[^] # Re: Transport
Posté par gUI (Mastodon) . Évalué à 2.
Génial, merci !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Transport
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Excellent… Merci.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Revenons aux rouleaux
Posté par Xinul . Évalué à 4.
L'antiquité avait tout compris avec le "volumen", ou rouleau.
Il suffit de reprendre l'idée des imprimantes à tickets de caisse, on met un rouleau de papier et plus de problème.
Rouleau qui peut après servir à un autre usage… (en cas de pénurie).
[^] # Re: Revenons aux rouleaux
Posté par gUI (Mastodon) . Évalué à 7.
Plus récemment tu avais les imprimantes matricielles avec le papier listing, celui avec les trous sur les côtés. Là aussi, pas de pages, juste du texte qui défile.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Revenons aux rouleaux
Posté par Xinul . Évalué à 2.
De souvenir le papier était quand même sous formes de pages, mais détachables non ? En tout cas sur la forme ça se lisait plus page par page qu'en défilement continu.
[^] # Re: Revenons aux rouleaux
Posté par gUI (Mastodon) . Évalué à 9. Dernière modification le 02 avril 2021 à 18:05.
Il était pré-découpé en effet, mais dans le cadre de l'impression de listing par exemple on ne découpait pas en pages du tout, c'était un simple
cat | lp. Le découpage se faisait (en suivant les pointillés) une fois les 2 ou 3 mètres de listing imprimés.L'autre intérêt de le pré-découper était de pouvoir le plier et le mettre à plat (bcp plus facile à stocker/ranger/transporter que en rouleaux).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Revenons aux rouleaux
Posté par orfenor . Évalué à 5.
D'ailleurs sur les bonnes imprimantes il y avait une barre de coupe afin de découper le listing où on voulait.
La pré-découpe n'avait aucun rapport avec les pages, c'était seulement comme tu dis une commodité.
[^] # Re: Revenons aux rouleaux
Posté par _kaos_ . Évalué à 4.
Salut,
Autre avantage : si les pages n'étaient pas numérotées et que par mégarde le document tombait, tout restait dans l'ordre (héritage de mauvaises expériences avec des lots de cartes perforées pas numérotées ?)
Matricule 23415
[^] # Re: Revenons aux rouleaux
Posté par Jean-Baptiste Faure . Évalué à 1.
Ce n'est pas le souvenir que j'en ai. Pour l'impression des listings d'exécution de programme, il y avait une mise en page automatique avec un cartouche sur chaque page.
[^] # Re: Revenons aux rouleaux
Posté par orfenor . Évalué à 3.
C'était propre a ton logiciel. Les miens ne faisaient pas ça et l'imprimante ne peut pas faire une mise en page automatique.
[^] # Re: Revenons aux rouleaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
À une époque j'utilisais le filtre d'impression
a2psqui ajoutait ce genre de jolies choses au postscript envoyé à l'imprimante. Maintenant, c'est plutôtvim -c 'set cmdheight=2' -c TOhtml -c write -c quit -c quitpour du code car ViM est souvent installé.J'ai souvent utilisé aussi
prcomme filtre sur les fichiers texte avant passage àlp“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Revenons aux rouleaux
Posté par Julien Jorge (site web personnel) . Évalué à 10.
C'est cool les rouleaux, combinés avec la tendance « on a des écrans horizontaux/larges, ça n'a pas de sens de restreindre la longueur des lignes », il y a moyen de se retrouver avec des rouleaux rédigés « en paysage ».
Cinq mètres de texte avant de revenir à la ligne, parce qu'on est au 21è siècle bon sang :D
[^] # Re: Revenons aux rouleaux
Posté par WrathOfThePixel . Évalué à 2.
Les gens qui pensent comme ça, c'est les même que ceux qui disent chocolatine, non ?
[^] # Re: Revenons aux rouleaux
Posté par jben . Évalué à 3. Dernière modification le 04 avril 2021 à 16:24.
Non. Du moins il existe au moins une personne qui pense que ça a un sens de restreindre la longueur des lignes, et qui nomme la chocolatine par son nom. Moi.
# zut loupé
Posté par refreketu . Évalué à 3.
J'aurais volontiers sauté dedans à pieds joints, mais trop tard, on est samedi matin.
[^] # Re: zut loupé
Posté par Liorel . Évalué à 3.
Oh, tu en auras l'occasion sous peu, puisque nous approchons d'un moment passionnant (si tu vis en France). Il y aura bien quelqu'un pour relancer le marronnier quinquennal des systèmes de vote ;)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: zut loupé
Posté par BFG . Évalué à 1.
J'en profite pour signaler une pétition déposée sur le site du Sénat (qui utilise France-Connect). On est malheureusement encore loin des 100000 signatures requises pour qu'elle soit inscrite à un ordre du jour sénatorial…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: zut loupé
Posté par BFG . Évalué à 1.
Pourquoi le système actuel serait-il plus adapté pour empêcher la prolifération des candidats ? Il y a quand même des filtrages, comme une condition de 500 signatures minimum, un non-remboursement de certains frais si le nombre de votes recueilli est trop faible (à adapter), etc.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: zut loupé
Posté par BFG . Évalué à 3.
Un candidat inconnu au bataillon n'aura pas beaucoup plus de chance d'être élu.
Très certainement aussi car c'est la plus problématique.
C'est donc un filtrage, car beaucoup de candidats potentiels hésiteront sûrement à se présenter s'ils doivent engager des frais non-négligeables pour "rien".
J'ajouterai que cette pétition vise à faire étudier ce système et le faire discuter. Il est dommage de rejeter une initiative intéressante de but en blanc sous prétexte qu'on vient de penser à un problème auquel il existe peut-être (déjà ?) une solution.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.