par Ploum, le 24-03-2022 | traduction de Xavier Dole, 1 avril 2025
J’ai souvent été déconcerté par la productivité des développeurs Open Source. Mais j’ai peut-être découvert leur secret : toujours avoir quelque-chose à faire sur leur ordinateur. Dès que vous avez quelque-chose d’urgent à faire qui n’est pas lié à l’ordinateur, la programmation open source vous semble vraiment importante.
Donc, dans un nouvel épisode de « J’aurais vraiment dû faire autre chose de ma vie », veuillez accueillir l’histoire suivante : « Offpunk a un nouveau moteur de rendu HTML », une longue méditation sur la lecture de HTML et l’amorçe de discussions philosophiques significatives.
Découverte des codes ANSI
Quand j’ai commencé à utiliser AV-98 comme client Gemini, j’ai pensé que c’était simple puisqu’il affichait simplement le contenu Gemtext à l’écran, remplaçant uniquement les URL par des chiffres. Je n’avais pas conscience que les titres devaient être colorés. Mais comment envoyer des couleurs à un terminal ? N’y a-t-il pas seulement des lignes blanches sur un fond noir ?
La réponse est dans les codes ANSI. Les codes ANSI sont des caractères spéciaux qui, une fois passés à un terminal, changent le « mode » du terminal. Si vous tapez « \e » suivi de « [« , le terminal le comprend comme « Control Sequence Indicator ». Vous pouvez ensuite taper différents nombres (séparés par « ; ») et terminer par « m ». Les différents nombres correspondent à différents modes. Par exemple en tapant « \e [1m » on passe en gras, et en tapant « \e [1;35m » on passe en gras et magenta. Vous pouvez fermer tous les modes ouverts avec « \e [0m ».
Il est limité à 8 couleurs de fond/avant-plan et à quelques autres modes comme gras, maigre, italique, souligné,…
C’est amusant jusqu’à ce que vous réalisiez que ces 8 couleurs peuvent être personnalisées en utilisant un autre code spécial. Ainsi en substance, votre terminal peut afficher n’importe quel caractère Unicode avec n’importe quelle couleur d’arrière-plan et de premier plan. (Tous les terminaux n’ont pas les mêmes capacités de coloration, mais…).
En lisant le code AV-98, je me suis également demandé à quel point il serait difficile d’affiches des pages HTML dans ce qui s’appelait déjà Offpunk. Si je pouvais afficher une page de texte avec un titre bleu, à quel point serait-il difficile d’afficher du HTML ? Je n’aurais besoin que de transformer les balises HTML en codes ANSI. Non ?
Pourquoi le HTML est une mauvaise façon de communiquer ?
J’ai hacké une première version affichant les liens en bleu et, oui, ça marchait ! Ce fut étonnamment facile! Mais plus j’essayais avec de nouvelles pages Web, plus je réalisais à quelle point la situation était mauvaise.
Tout d’abord, HTML est vraiment difficile à analyser pour une raison simple : l’espace et les caractères de retour peuvent agir complètement différemment selon l’endroit où ils se trouvent dans la page. En fait, sauf dans <PRE>, on pourrait dire que vous pourriez laisser tomber les retours. Sauf que parfois ils doivent être considérés comme des espaces (si vous ne le faites pas, certaines pages aurontleurtextecollésansespace).
Mais c’est seulement quand le HTML est bon. La plupart du temps ce n’est pas le cas. Ma routine HTML2ANSI initiale a commencé à se développer organiquement pour gérer tous les cas qui se présentaient. C’était essai et erreur : ajoutez un espace ici, rechargez, voyez si ça semble correct, ajoutez un autre strip() là… Pas d’architecture, code aléatoire pur.
En observant le code source, je me suis retrouvé plusieurs fois à me demander si je devais afficher ce que les gens avaient évidemment l’intention de dire ou si je devais afficher ce que le HTML disait. Un petit exemple évident : Les sites Web WordPress utilisant Jetpack ont une partie de leur image dupliquée. La raison en est que l’une des images est derrière un attribut « lazyloading » tandis que l’autre est dans une balise «
Les outils sont tout simplement mauvais et produisent un HTML affreux. Si vous n’êtes pas convaincu, regardez la source d’une page générée par le pseudo-minimaliste Medium. En tentant d’analyser HTML, il devient évident que nous avons perdu tout sens. Les gens ont écrit, les outils transforment cet écrit en un mumbo-jumbo vide de sens et moi j’essayais d’écrire un outil pour retrouver le sens original.
Mais les outils ne sont pas les seuls à blâmer…
Les gens écrivent mal
Lorsque j’ai ajouté le support pour le gras et l’italique, quelque chose d’étrange est apparu : les pages de test que j’utilise depuis le début perdaient en lisibilité ! Le texte seul était bon, mais les gens ne peuvent s’empêcher d’ajouter beaucoup de choses, de fantaisies (gras, italique,…) sur lui, comme s’ils craignaient de ne pas être remarqués. Chaque page HTML fait penser à un enfant qui fait des trucs stupides pour attirer l’attention de ses parents.
Ouvrez un livre ; ouvrez 10 livres autour de vous. Notez le nombre de phrases en gras, de styles variés et de mots colorés que vous voyez. Sauf dans certains livres techniques très modernes, il n’y en a pas. Vous pouvez parfois trouver de l’italique pour indiquer une citation, mais c’est assez rare. Je fais bien sûr référence à des livres qui ont été publiés avant que les écrivains ne commencent à utiliser MS Word.
Comme l’a dit Neal Stephenson dans « Au commencement était la ligne de commande », gras n’a d’abord été utilisé que pour les titres. Puis MS Word est venu sans aucun support pour les styles de titre/sous-titre formel. Le bouton « gras » a alors été mis en évidence et les gens devaient styler leurs titres manuellement. Mais autre chose est arrivé : les gens ont commencé à mettre gras et italique partout. Parce qu’ils pouvaient.
En lisant toutes ces pages Web, je me suis rendu compte à quel point cette débauche de « styles » était symptomatique d’un fort sentiment d’insécurité. Peur de ne pas être lu. Peur de ne pas être cool. Peur d’être ennuyeux. Peur de perdre son public. Et pourtant, combien meilleurs étaient la plupart des textes sans aucun style.
Alors que je lisais « L’âge des low-tech » de Philippe Bihouix, je suis tombé sur l’un de ces cas d’insécurité. L’auteur a mis le mot « JAMAIS » en majuscules, espérant probablement faire un point. Il semble que l’auteur n’était pas sûr de son argumentation qu’il l’estimait faible et a donc tenté de compenser. Le point était quelque chose comme « l’impression 3D n’est pas une solution car de vraies constructions comme les maisons ne peuvent JAMAIS être imprimées en 3D ». Ce qui est évidemment faux (ou du moins il faudrait expliquer pourquoi les bâtiments imprimés en 3D actuels ne sont pas imprimés en 3D). Sans le tout-majuscules, cela aurait juste été une erreur dans un livre, quelque chose de compréhensible. Avec le tout-majuscules, l’auteur a perdu de la crédibilité pour de nombreuses pages.
Toute erreur qui peut être faite…
Donc, en substance, les gens utilisent des outils merdiques qui produisent du code merdique et ils les utilisent aussi mal que possible. Nous pouvons dire en toute sécurité que toute erreur qui peut être faite sera faite.
Il en va de même pour Gemini. Mais comme Gemtext est très simple et comporte très peu d’outils, cela réduit considérablement la surface d’erreurs possibles. Les erreurs ne peuvent être faites que ligne par ligne. Comme ce cas où quelqu’un parlait d’un hashtag et que celui-ci est apparu au début de la ligne, transformant la ligne en un titre.
Il y a toutefois une vraie erreur encore possible avec Gemtext : Preformatted.
J’ai tout vu : des gens oubliant une ligne « preformatted », inversant ainsi formatted/preformatted, d’autres ne fermant pas une ligne preformatted ou encore : quelques gemlogs alternant entre formaté/préformaté à chaque paragraphe. La seule explication que j’ai trouvée était que ça avait l’air cool dans leur client de test. Et si leur client changeait la couleur de fond pour preformatted ? Alors leurs messages seraient rendus comme un joli patchwork de couleurs.
C’est un énorme problème car Offpunk n’enveloppe pas les textes preformatted, en supposant qu’ils sont une sorte d’ASCIIART. Ces paragraphes ont donc été affichés comme une longue ligne non enveloppée.
Si une erreur peut être commise, elle le sera.
À propos de Wrapping (enveloppement)
Cela semble évident lorsque vous lisez des textes, mais dès qu’une ligne est plus longue que votre écran, cette ligne doit être enveloppée pour que le texte continue à la ligne suivante..
L’enveloppement (wrapping) est loin d’être trivial si vous ne voulez pas couper au milieu des mots. Vous devez compter les caractères puis, une fois un seuil atteint, couper à la séparation de mot la plus proche.
Mais rappelez-vous ce que je vous ai dit sur les codes ANSI et les couleurs : lorsque vous voyez une ligne colorée sur un terminal, il y a des caractères invisibles ; beaucoup d’entre eux. Alors l’enveloppement est hésitant et peut envelopper trop tôt.
Si vous avez un titre Gemini que vous voulez en bleu vif, les séquences ANSI pour ouvrir et fermer tout compteront 12 caractères. Votre enveloppement sera vraiment court.
Ce n’est pas un problème énorme jusqu’à ce que vous commenciez à travailler avec des lignes HTML où vous pouvez avoir 4 ou 5 liens pas ligne. Vous pouvez commencer l’enveloppement avant d’avoir affiché le moindre caractère !
Les modes ANSI doivent être conservés à la ligne suivante mais j’ai observé de nombreuses singularités. D’après ce que j’ai vu, il est recommandé de fermer tous les codes ANSI avant la fin d’une ligne. Cela rend l’enveloppement encore plus difficile : vous devez identifier toutes les séquences ANSI ouvertes, les fermer et les rouvrir sur la ligne suivante…
… Ce qui permet de résoudre exactement le problème que python-ansiwrap résout. Et ils ont fait du bon travail avec ça.
Afficher des images
En lisant des pages Web avec Offpunk, j’ai réalisé une fois que je manquais une information importante. j’ai chargé la page dans Firefox et – oui –, un paragraphe entier (une citation) manquait. Il m’a fallu lire le code source pour comprendre que la citation n’était pas un texte mais une image.
La solution facile pour éviter ce problème était de rendre les images sous forme de liens. Si vous vouliez voir une image, vous suivriez simplement le lien et l’image s’afficherait dans votre visionneuse d’image (Feh, dans mon cas).
Mais rapidement, j’ai commencé à ouvrir toutes les photos, curieux de voir ce qu’elles étaient. La plupart des images sur le web sont inutiles. Elles servent à ajouter du « sentiment » au sens. Comme « gras » et d’autres styles, elles servent seulement à attirer l’attention sur le contenu. Je suis coupable comme tout le monde. Pendant des années j’ai essayé de trouver une image accrocheuse pour chaque article de mon blog. Cela a encore été renforcé par le fait qu’un lien sans image n’a aucune chance de prospérer sur Twitter ou Facebook. C’est même devenu une sorte de rituel artistique de jumeler un article de blog avec une image totalement sans rapport.
Quand j’ai découvert la console il y a plus de 20 ans, j’ai commencé à jouer avec Libcaca, qui transformait les images en asciiart. J’ai fait l’expérience mais – vue la petite taille d’un site web – une image Libcaca n’aide pas du tout. C’est amusant mais pas moyen de reconnaître quoi que ce soit.
Alors l’univers me parla de Chafa. Pour l’anecdote, j’effaçais les paquets inutilisés de mon ordinateur quand j’en ai trouvé un appelé Neofetch. J’ai fait un « apt-cache show neofetch » pour voir ce que c’était et j’ai été intrigué par une dépendance appelée « chafa ».
Vous souvenez-vous que votre terminal peut afficher n’importe quel caractère Unicode avec un premier plan personnalisé et une couleur d’arrière-plan ? Eh bien Chafa utilise cela pour transformer n’importe quelle image en un bloc configurable de texte coloré. Ce qui est vraiment intéressant, c’est que la plupart des images sont reconnaissables. J’ai aussi trouvé « timg », qui fait exactement la même chose que Chafa, bien que plus lentement.
J’ai pensé qu’il serait amusant d’avoir des images de rendu Chafa dans Offpunk. Juste comme preuve de concept, j’ai essayé… et j’ai rapidement été convaincu. Cela fonctionnait si bien que je pouvais facilement dire si une image était suffisamment importante pour que je l’ouvre ou qu’elle était seulement décorative et que je pouvais la sauter. En un mot, c’était « utile ». Un outil supplémentaire pour extraire des informations que les gens enterrent délibérément tout en essayant de les promouvoir.
Une page web avec des images rendues dans Offpunk. Remarquez comment vous pouvez reconnaitre que IMG 11 est un mème tandis que IMG 15 est une capture d’écran.
Avec la version 1.8, Chafa a ajouté le support pour une sorte de « kitty-image-protocol », quelque-chose que je ne comprends pas mais qui permet au Terminal Kitty d’afficher des images en pixels parfaits. Timg avait déjà un support pour cela. Les images en pixels parfaits ne peuvent pas être intégrées dans le texte, mais cela signifiait tout de même que je pouvais directement les afficher dans Offpunk. Et, oui, cela fonctionne lorsque vous accédez directement à l’image.
Offpunk affichant une image à partir d’un gemmlog que vous devriez suivre
Pour un meilleur résultat, utilisez le terminal Kitty et Chafa 1.10. Si vous avez un Chafa plus ancien, installez également Timg pour avoir le meilleur des deux mondes.
Réécrire tout à partir de zéro
Toute cette assiette de spaghettis hackée fonctionnait assez bien, mais c’était impossible à entretenir. Le code de rendu HTML était une pure devinette aléatoire. Ansiwrap a parfois donné des résultats étranges et les performances étaient minables. Une ligne de 40 caractères produite par Chafa pouvait contenir jusqu’à 1000 caractères, qui ont été analysés par Ansiwrap.
En lisant le code source d’Ansiwrap, j’ai réalisé qu’une tâche difficile était d’identifier d’abord les codes ANSI dans un texte. Quelque chose que je pourrais éviter en le faisant moi-même.
Donc, en substance, de la même façon que je faisait un texte plein de codes ANSI, puis l’enveloppais avec Ansiwrap, pourrais-je le faire dans l’autre sens ?
J’ai commencé à écrire un nouveau moteur de rendu qui sauverait la position de chaque futur code ANSI sans les insérer. Ensuite, je les envelopperais ligne par ligne, en insérant des codes ANSI seulement après l’enveloppement, tout en étant suffisamment intelligent pour les fermer avant la fin de ligne et les réouvrir en début de ligne suivante.
Et les images de Chafa seraient insérées sans être enveloppées du tout.
Ce n’était pas une tâche facile et j’ai même ajouté un commutateur BETA pour conserver l’ancien moteur de rendu pendant que je travaillais sur le nouveau. Mais j’ai rapidement réalisé qu’il faisait un meilleur travail.
Au lieu de transformer le HTML en ANSI, j’essayais d’abord de comprendre le HTML, puis de construire une représentation significative. Par exemple, newparaphaph() et newline() sont deux fonctions différentes parce qu’elles ont une signification différente. Pour l’anecdote, le premier moteur de rendu ajoutait tellement de lignes vides que je devais supprimer chaque bloc de plus de trois lignes vides avant d’afficher le résultat.
Ainsi, à partir de la version 1.2, Offpunk a un tout nouveau moteur de rendu, aussi bien utilisé pour Gemini, Gopher et RSS. Veuillez tester vos capsules et sites Web préférés et signaler tout problème.
Utiliser le moteur de rendu sans Offpunk
Un moteur de rendu HTML2ANSI semble très utile et je me demande si je devrais le publier en tant qu’outil autonome. Vous pouvez déjà le tester assez facilement avec le script python suivant dans le même dossier que Offpunk :
#!/usr/bin/env python3
de offpunk import HtmlRenderer
f = open("index.html")
contenu = f.read()
f.close()
rend = HtmlRenderer(contenu,"www.test.com")
#affiche le résultat en moins
rendu.display()
#ou le mettre dans une variable
corps = rend.get_body()
print(corps)
Rendre le Web lisible
Je suis fier de dire que mes premiers objectifs ont été atteints : supprimer toute dépendance à python-ansiwrap, améliorer les performances avec des images et rendre le code plus maintenable.
En dehors de Ansiwrap, Offpunk utilise deux bibliothèques pour analyser le web : le vénérable BeautifulSoup 4 (python-bs4), qui fait un travail remarquable d’analyse du HTML. L’analyse est l’acte de transformer un texte en une représentation informatique utilisable. Le rendu est le contraire : transformer la représentation informatique en quelque chose qu’un utilisateur peut lire/regarder. Meilleure est l’analyse, plus simple est le rendu.
L’autre est python-readability, qui supprime les cruft (code redondant ou inutile) indésirables d’une page HTML. Python-readability transforme HTML en HTML, mais avec moins de choses. La plupart du temps, cela fonctionne très bien, permettant à Offpunk d’afficher uniquement le corps de l’article que je veux lire.
Mais parfois, cela enlève trop. Dans ce cas, Offpunk permet de contourner python-readability avec la commande « view full » (ou « v full »). À partir de 1.2, vous pouvez marquer une page et son mode, de sorte que vous passez automatiquement à « full » pour certaines pages. Cela se fait avec un hack très vilain (ajouter « ##offpunk_mode=full » à la fin de l’URL, et croiser les doigts pour que dans la vie réelle, aucune URL n’ait cette chaîne de caractères dans leur URL).
Sans python-readability, je n’aurais pas pu ajouter le support web à Offpunk. Cela aurait été décourageant. Mais maintenant que j’ai un moteur de rendu HTML amélioré, je commence à me demander si je ne pourrais pas faire de python-readability une dépendance optionnelle. Serait-il utile pour quiconque de ne pas installer python-readability ?
Il y a une bonne raison de ne pas permettre l’exécution de Offpunk sans python-readability. Avec readability activé, la plupart des pages ont entre 0 et 20 ou 30 liens. L’exécution de « offpunk -sync » implique d’effectuer autant de requêtes pour précharger le contenu et les images.
Mais en mode « full », la plupart des pages comportent entre 100 et 500 liens. Bien sûr, la plupart sont complètement inutiles. Dans ces conditions, utiliser Offpunk pour surfer sur le web sans readability pourrait être un cauchemar.
Entamer une conversation
J’ai créé mon premier site web en 1998 et commencé mon blog encore actif en 2004. Pendant toutes ces années, je publiais pour attirer l’attention, obtenir un lectorat. Je cherchais le « succès ». J’en ai : livres publiés, invité à donner des conférences, des emplois offerts, j’ai même été par deux fois reconnu à l’étranger du fait de mon blog. Mais ce n’était jamais assez. Et ce n’est toujours pas assez. Je ne me sens pas particulièrement accompli.
Durant les 20 dernières années, j’ai tenté de devenir un écrivain à succès en faisant tout ce que je pouvais pour attirer l’attention sur mon écriture. Ces dernières années, je me suis consacré de plus en plus à l’écriture, publiant de moins en moins et donnant encore moins de temps au marketing.
En étant forcé d’analyser toutes les choses inutiles (styles, cruft,…) que d’autres ont mis autour de leur écriture, j’ai été forcé de réaliser que je faisais – et pourrais encore faire – la même chose, et combien accorder trop d’importance à l’apparence est préjudiciable au contenu. Toute personne suggérant que Gemtext devrait prendre en charge les couleurs devrait être obligé d’écrire un analyseur ANSI en premier. Toute personne suggérant que le formatage Gemtext ne suffit pas à exprimer correctement ce qu’elle veut exprimer devrait ouvrir un vieux livre.
La plupart des gens essaient de contourner le fait que l’écriture est difficile. Vraiment dur. Ils espèrent partager des émotions et des indices non verbaux à travers des émojis, des couleurs, des fantaisies typographiques. Le problème est que – contrairement au langage écrit –, ces formes d’expression ne sont pas explicites. Vous ne transmettez pas ce que vous voulez transmettre, vous le rendez moins compréhensible. Si vous ne pouvez écrire sans couleurs ni émojis, c’est probablement parce que vous ne savez pas vraiment ce que vous voulez dire. Voilà pourquoi l’écriture est si difficile. C’est dur mais c’est payant. Lorsque vous écrivez avec seulement des mots, non seulement vous communiquez mieux avec les autres, mais vous communiquez également avec votre moi présent et futur.
« Ce qui se conçoit bien s’énonce clairement et les mots pour le dire viennent aisément » (Boileau)
Je suis toujours étonné par la vacuité des pages Web les plus populaires une fois affichées dans Offpunk.
Offpunk a fait la une de Hackernews, ce qui m’a amené à rompre ma déconnexion temporairement parce que j’étais curieux de suivre d’autres liens répercutant l’info qui obtenaient plus de votes. Ils étaient superficiels, vides et avaient rarement plus de 200 mots. En recherchant Offpunk sur Google le même jour a révélé que les premières pages étaient principalement des remixes informatiques du READEME Offpunk. Le web est plein de contenu automatique essayant d’imiter ce qui a réussi. Il y avait même deux vidéos Youtube dans les premiers résultats Google, les deux étant la lecture informatique du README pendant que le site Web est affiché. Le vrai site Web Offpunk était seulement sur la deuxième page, ce qui démontre comment le Web est enterré dans les contenus générés automatiquement et à quel point le moteur de recherche dominant est mauvais.
Je n’ai pas reçu plus d’emails ce jour-là que lorsque je poste sur ce gemlog.
Ce succès que tout le monde recherche est faux, de courte durée. Il n’est même pas fini que vous devez déjà courir pour le prochain succès.
Avec Offpunk, je peux toujours lire les gens que j’aime sur le Web. Je suis leurs flux RSS. Cela me donne l’impression que je suis toujours sur Gemini ou Gopher. C’est marrant comme – chaque fois que je trouve quelque chose de profond et significatif à lire sur le Web, il rend bien dans Offpunk. Ça donne l’impression que le sens et la présentation sont en quelque sorte liés.
J’aime aussi écrire sur Gemini parce que je sais que ça ne peut pas amener le succés. Je peux y écrire de longs trucs comme celui-ci. Ils seront lus par des personnes qui s’y intéresseront. Pas beaucoup. Peut-être aucune. Mais si vous l’avez lu jusqu’à présent, alors cela a certainement un impact sur vous. J’aime partager mes pensées avec vous. Vous allez – consciemment ou non – les traiter. Il se peut même qu’un jour vous produisiez quelque chose qui aura été impacté par que vous avez lu aujourd’hui… et plus tard, je pourrais même vous lire sans le savoir.
Tout cet article a été fortement influencé par beaucoup de gens dans l’espace Gemini. Ils m’ont fait réfléchir. Vous m’avez probablement fait réfléchir. J’ai évolué grâce à ce que j’ai lu. Parfois, en vous lisant, j’ai eu envie de répondre. Mais il n’y avait pas de moyen rapide et facile pour le faire. Alors ma réponse s’est perdue… ce qui signifie soit qu’elle n’était pas importante, soit qu’elle a voyagé avec ma pensée et s’est cristallisée dans ce post ou un suivant.
Nous avons entamé une conversation longue, lente et significative. Le genre de conversation sur laquelle chaque percée humaine a été conçue. Merci d’y avoir participé.
Ce n’est que le début de notre conversation.
Lien vers l’article original en anglais
Notes du traducteur (moi-même) : Vous pouvez bien sûr laisser un commentaire et je ferai de mon mieux pour éclairer votre lanterne. Mais je ne suis que le traducteur. Je crois avoir compris à peu prêt la philosophie de l’ensemble, compris plus ou moins la logique de la partie technique, mais très loin de comprendre le comment (programmation, codage, …). Si vos interrogations portent sur ce dernier aspect des choses, mieux vaut que vous alliez directement visiter le site de Ploum, l’auteur du texte.
Xavier Dole
Laisser un commentaire