💾 Archived View for kujiu.eu › fr › 2020 › 07 › 10_generation_pdf.gmi captured on 2023-12-28 at 15:21:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
By Kujiu
Le 10 Jul 2020 Ă 21:50
Avertissement: Désolé, cet article n’a pas encore de version en anglais.
Le mois de juin n’a pas été très satisfaisant en terme d’efficacité sur le projet. La faute en est clairement au rattrapage dans ma formation. Je suis arrivé en Belgique il y’a quelques années déjà , et je ne connais toujours pas la langue la plus parlée du pays. Je prends donc des cours du soir de néerlandais depuis la rentrée scolaire 2019. J’ai validé le niveau A1 en fin de mois.
Pour ceux qui ne le savent pas, la Belgique a trois langues officielles : le néerlandais, le français et l’allemand. Chacune d’elles est parlée dans une zone bien précise. La Flandre parle néerlandais, Bruxelles - une enclave en Flandre - principalement français et un peu néerlandais, et enfin la Wallonie en français - exceptée une petite zone à l’Est où l’allemand est de mise. Et avec ça, je n’ai même pas parlé des communes à facilités, dans lesquelles il est possible de parler une autre langue que celle de la région. Bien sûr, chaque langue dispose de sa communauté, et donc de son gouvernement. Et chaque région (Flandre, Bruxelles et Wallonie) a également son gouvernement. Donc, si l’on compte tout cela, nous avons six gouvernements (néerlandophone, germanophone, francophone, flamand, wallon et bruxellois) auxquels il faut encore ajouter un gouvernement fédéral. Comment ça, c’est compliqué ? Non peut-être…
Toujours est-il que je vis à la frontière linguistique franco-néerlandophone et je souhaite ne plus être coupé de la moitié de la culture du pays. L’objectif est clair : niveau A2 fin septembre et potentiellement B1 dans un an. Et je peux vous dire que je m’en donne les moyens ! J’ai acquis un gros rythme de travail, il faut dire aussi que les sept premiers mois de formation ont été plutôt chaotiques : l’école n’avait strictement aucune mesure d’adaptation à ma vue. J’ai pu trouver les ressources pour rattraper le retard accumulé, et je continue avec cet élan.
J’ai travaillé aussi sur une partie technique en parallèle de la formation : l’unification des médias. J’utilise un logiciel particulier pour l’écriture, dédié normalement à la rédaction de documentation. Il s’agit de
. Il me permet à la fois de créer un site web, un blog, une histoire, un *PDF*, un *ePub* et je compte bien l’utiliser aussi pour générer l’audio et préparer les projets vidéo. Oui, rien que ça ! J’ai donc passé un mois à peaufiner le thème global du Nerv Project, à faire en sorte que ce thème fonctionne quelque soit le média. Il reste quelques bugs, vous pouvez vous en rendre compte en tentant d’imprimer cette page.
Écrire un univers entier, c’est bien. Mais c’est encore mieux s’il y’a des lecteurs. Je ne peux pas vous dire grand chose ici pour ne pas gâcher la surprise, mais je réfléchis à d’autres formats pour vous proposer du contenu exclusif et amusant. Je me pose aussi beaucoup de questions sur une éventuelle officialisation du Nerv Project. Bref, j’ai beaucoup de sujets en suspens sur ces questions et ce sera exploré dans les prochains mois. Je rappelle que vous pouvez rejoindre le salon IRC, le serveur Discord ou encore le serveur Matrix. Tous les liens sont sur le site du
.
J’ai eu aussi un retour plutôt désagréable d’une certaine personne, qui se reconnaîtra peut-être. Nous sommes dans une période où beaucoup de choses sont remises en question, tant sur les inégalités sociales que sur les expressions utilisées. Tous mes travaux sont stockés sur un système pour la gestion des versions, nommé *git*, et dont la branche principale est nommée par défaut *master*. Certains auront été impactés par les quelques jours de maintenance sur le serveur, il s’agissait de renommer ce terme devenu problématique par le terme *main* bien plus juste dans son sens et bien plus neutre politiquement parlant. C’est une grosse étape, avec beaucoup de travail. Ce terme n’est pas le seul remis en question, il y’a notamment les *whitelists* pour les éléments à laisser passer et les *blacklists* pour les éléments à bloquer. Il semblerait, dans les recherches que j’ai rapidement effectuées, que ce terme dérive de la couleur des balles utilisées lors de votes à bulletin secret. Une balle blanche pour l’accord, une balle noire pour le désaccord. Du moins, pour certaines sources non académiques. Si vous connaissez des sources fiables, vous pouvez me les donner en commentaire. En attendant, je ne tiens pas compte de cette hypothèse.
Cependant, le mot *black* signifiait à la fois quelque chose de mauvais ainsi que la punition et la couleur noire. Le terme *blacklist* est apparu en 1590, en pleine exploitation esclavagiste et notamment des personnes à la peau foncée. Ce terme est resté jusqu’à nos jours et je ne nie aucunement que son origine est contestable moralement. Je conçois parfaitement que ce terme est problématique. Et puis, la composition du mot ne donne pas une définition claire et juste du principe. Des termes comme *blocklist* et *acceptlist* seraient tellement plus élégants.
Malheureusement, ces concepts sont utilisés depuis les débuts de l’informatique et perdurent à de très nombreux endroits. Autant je pouvais corriger le terme dans le nom des versions, moyennant déjà pas mal de travail, autant il me paraît infaisable de modifier le reste. C’est pour cela que je ne le ferai pas. Il n’y a ni alternative convenable me permettant d’utiliser des logiciels exempts de ces termes ni solution viable pour les modifier moi-même. Il faudrait que je réécrive de nombreuses lignes de code, que je m’assure qu’elles ne soient pas supprimées à la moindre mise à jour, etc. Il ne s’agit plus de jours de travail mais d’années. Qui plus est, quand le logiciel répond aux termes utilisés dans des normes (je pense notamment au serveur mail). Les développeurs de certains logiciels se sont emparés du problème et s’occupent déjà de corriger.
Cette clarification étant faite, je ne tolèrerai aucune diffamation me concernant en raison d’un logiciel tiers sur lequel je n’ai pas la main.
Et puis, quitte à être dans les sujets polémiques, le Nerv Project n’utilisera aucunement une écriture mettant à l’écart une frange de la population par son côté inaccessible. Le point médian dit inclusif empêche aux personnes souffrant de dyslexie ou de cécité de lire. Encore une fois, je comprends le besoin égalitaire face à la langue mais je refuse d’être tout simplement interdit ou d’interdire à qui que ce soit la lecture pour privilégier un autre groupe. Une écriture inclusive doit l’être pour tout le monde, sans mettre des gens sur le bord de la route « parce qu’ils sont minoritaires » ou parce que les systèmes technologiques nécessaires ne peuvent pas être compatible. Et je vais être très dur sur un point : IL EST TOTALEMENT HORS DE QUESTION QUE J’ABANDONNE LE BRAILLE. Oui, il n’y a pas de caractère officiel pour le point médian en braille, mais ce n’est pas une raison pour l’interdire. Si ce que je vous dis vous semble aberrant, sachez que cela m’a été reproché.
Je vous rappelle que je fais aussi partie de minorités, oui au pluriel. Gay et légalement aveugle. Et la langue française n’est clairement pas sympathique non plus dans ces cas. Mais revenons à nos moutons. Je suis totalement preneur si un accord sort concernant une langue inclusive, simple, qui ne pose aucun problème. Mes textes reprennent notamment des noms de métier féminisés, il y’aura des personnages féminins construits avec autant d’attention que les autres, etc. Et il est absolument hors de question qu’il en soit autrement. Et plus encore, si vous lisez entre les lignes de l’univers du Nerv Project, vous vous rendrez compte que cette agence secrète fictive peut prendre tout un tas de qualificatifs peu glorieux. C’est fait exprès, il faut bien qu’une chose existe dans une fiction pour la dénoncer ou pour poser des questions de société. Et dans les futurs écrits, vous allez apprendre à détester le fabuleux cardiologue. Et pas qu’un peu.
Concrètement, j’évite au maximum d’utiliser le pluriel directement à un ensemble de personnes listées. Ainsi, je n’écrirai pas « Marc, Martine et Mehdi sont gentils » mais « le groupe d’amis faisait preuve d’une gentillesse à toute épreuve » (groupe est masculin singulier) ou « les personnes » (féminin pluriel) ou encore « les gens » (pluriel, genre selon la position dans la phrase).
Je regrette fortement le manque du neutre dans la langue française, et je ne serai pas contre pour définir, par exemple, un genre actuel comme neutre et l’autre comme « genré ». Si on prend le masculin comme neutre, on dirait « Marc est gentille », « Martine est gentille » mais « Marc et Martine sont gentils ». Mais on peut aussi choisir l’inverse. Cette approche aurait l’avantage de créer peu de différences dans la langue, d’être totalement inclusif vu que tout le monde a le même pronom et le même accord, et d’être simple pour tout le monde. C’est une proposition comme une autre. Je sais que certaines personnes proposent l’accord de proximité, mais je trouve la règle moins simple à appliquer. Il n’y a pas de consensus aujourd’hui sur ces sujets-là et je ne veux pas non plus perdre un public non sensibilisé à ces questions. C’est pour cela que je me tiendrai à appliquer les règles de français telles qu’elles existent aujourd’hui, en utilisant un mot valise pour parler d’un groupe plutôt que de référencer directement plusieurs personnes directement par un pronom. Et si jamais un tel cas se produirait, il s’agirait juste d’une faute à la relecture, vous pourrez directement me le signaler et je corrigerai le texte.
Ainsi se termine la partie non technique. Il n’y aura pas plus d’actualités dans la suite de cet article.
Revenons donc à ce qui m’a occupé ce mois-ci. *Sphinx* exporte nativement en *PDF* en utilisant *LaTeX*. Cette manière de faire ne me convenait pas pour une raison toute simple : il faut maintenir à la fois un thème pour *HTML* et un thème pour *LaTeX*. Et en plus, les spécificités de *Sphinx* rendent le thème *LaTeX* difficilement personnalisable. C’est donc beaucoup de travail supplémentaire, à maintenir. C’est pour cela que j’ai écrit deux extensions très simples pour *Sphinx*. Il s’agit de
et de
. Les deux font exactement la même chose, mais pas avec le même moteur. J’utilise donc la sortie *HTML* de *Sphinx*, mais en version un seul fichier à la sortie, puis j’applique une conversion du *HTML* vers le *PDF*. Dans le premier cas, j’utilise *WeasyPrint*, basé sur *Cairo*, qui propose une conversion directe. Dans le second, il s’agit d’une impression lancée avec le moteur de *Chromium*.
Tous les moteurs de rendu ont des approches différentes et tous ne supportent pas de la même manière les différents flux et les attributs CSS. Et malheureusement, la partie impression est relativement peu implémentée.
Le thème *HTML* du Nerv Project pour *Sphinx* est assez particulier pour plusieurs raisons. Il est prévu pour être fonctionnel pour les sorties *HTML*, *PDF* via *sphinx_pyppeteer_builder* et *ePub*. Il est disponible pour tout le monde
. Je ne peux malheureusement pas le rendre compatible avec *WeasyPrint* en raison de certaines complexités du *CSS* non prises en charge. Et il me reste encore quelques bugs sur la taille de certains blocs, laissant ainsi de grands vides avec le format impression. À noter que j’ai dû utiliser une table pour de la mise en forme. Je n’aime pas ça, mais c’est le seul moyen de garder des entêtes et pieds-de-pages fixes.
Le thème fonctionne cependant parfaitement bien pour l’affichage du site web. Il dispose de ses quatre jeux de couleurs en mode site web uniquement et d’un cinquième pour l’impression. Le format *ePub*, quant à lui, ne permet pas de gérer des jeux de couleurs en fonction du thème du système. Il a donc fallu faire un choix sur ce point, et il reprend donc le mode clair, car c’est celui qui est généralement préféré par l’utilisateur. En plus, c’est celui qui est le plus logique pour des liseuses à encre électronique.
Tant que nous sommes dans les problèmes liés au format *ePub*, le retour de mes écrits est très mauvais avec le programme *epubcheck*. J’ai un grand nombre d’erreurs. J’ai pu corriger une partie liée au thème. J’utilise même un module de mon cru,
, pour pouvoir utiliser des icĂ´nes de
au format *SVG*, et celui-ci empêche aujourd’hui la génération d’un *ePub*. Il me reste donc du travail pour mettre tout ça au point, et voir pourquoi *Sphinx* lui-même me provoque des erreurs à la vérification.
Enfin, une dernière action de ce mois-ci change beaucoup de choses sur l’infrastructure. J’ai abandonné *GitLab* pour revenir à *Gitea*. Je perds énormément de fonctionnalités que je n’utilisais pas et quelques unes qui m’étaient utiles. Mais ce changement me libère beaucoup de ressources. *Gitea* consomme moins en *RAM* et en processeur. Ça soulage un serveur qui est déjà surchargé. Il me reste à me pencher sur quelle solution *CI/CD* je vais déployer pour remplacer celle que j’ai perdue.
Parlons d’ailleurs architecture. Aujourd’hui, j’utilise un seul serveur sur lequel tout est installé, sans réelle séparation entre services. Il héberge à la fois le serveur mail, les sites web, mon serveur *XMPP*, et me sert de bureau distant en *CLI*. Bref, ce n’est pas très propre, surtout qu’il s’agissait à la base d’un bureau distant et rien d’autre. Le choix de la distribution Linux (Arch) n’était pas insensé à ce moment-là .
Une telle architecture ne va aujourd’hui plus du tout, les besoins grossissent. Et donc une refonte complète est à prévoir. Je regarde actuellement différentes solutions pour cela. J’ai déjà identifié quelques scénarios à mettre en œuvre, pour automatiser la maintenance, la mise à jour des sites, la création de nouvelles machines, l’élaboration d’un plan de reprise d’activité et j’en passe. Il va y avoir un gros travail dans les mois à venir sur tout cela. Je peux déjà vous dire que j’ai sélectionné *SaltStack* et *Zabbix*, et que je lorgne sur *Uyuni*, et peut-être *OpenBuildService*. Ce sujet sera très probablement abordé le mois prochain de manière bien plus détaillée.
Déclaration deconfidentialité
Le Kujiu's Labs est produit par Nerv Project ASBL.
ISSN 2736-7649
Nerv Project ASBL - BCE 0756.741.342 - TVA BE0756741342 - KBR Éditeur 15066 - IBAN BE02751210684040 - BIC AXABBE22.
Licence EUPL 1.2
