Conversion de fichiers

Conversion des fichiers issus de sites statiques pour les incorporer dans Pelican

Conversion à partir de Dokuwiki

Premiers essais

En me connectant en FTP, je récupère les fichiers de toutes les pages (dossier pages). Ils sont au format .txt. Ma technique est de recycler un vieux shell qui servait à convertir des images (avec jpegtran), afin de l'adapter avec Pandoc.
En m'inspirant de ce shaarlink, j'écris donc le shell suivant :

1
2
3
4
5
6
7

#!/bin/bash
in_path=$1
out_path=$2
for i in $in_path/*.txt; do
    out_file=$(basename $i)
    pandoc --from dokuwiki --to markdown_strict -o $out_path/$out_file $i
done

Pour l'appeler, avec un terminal situé dans le répertoire où se trouve ce shell, j'utilise la commande sh ./convert-dokuwiki.sh ./pdu-wiki-in/ ./pdu-wiki-out/ (je ne suis pas certain que le ./ soit nécessaire).

Bon, pour l'instant le résultat me donner deux problèmes : les fichiers de sortie ont toujours l'extension .txt (plutôt que .md) ; et le format markdown dans le fichier ne me semble pas correct. Il va falloir vérifier la commande pandoc et effectuer quelques tests.
D'ailleurs, j'avais initialement un problème car dans la version initiale de Pandoc que j'avais, la commande --from dokuwiki n'était pas connu. Normal, j'avais la version 2.5. Pour parvenir sur une version + fraîche, j'ai effectué les commandes suivantes¹ :

sudo apt purge pandoc
wget https://github.com/jgm/pandoc/releases/download/3.1.9/pandoc-3.1.9-1-amd64.deb
sudo dpkg -i pandoc-3.1.9-1-amd64.deb

Et j’atterris donc avec la version… 3.1.9. Et n'ai plus d'erreurs.

Contraintes de Pandoc

Suite aux premiers essais décrit ci-dessus, j'ai voulu par ailleurs convertir ponctuellement un fichier markdown (celui pour les listes de plats) et j'ai découvert qu'il pouvait y avoir de sacrées différences entre les différents formats de sortie : markdown_strict, markdown, markdown_gfm, etc.

Second essais

Je me base sur les premières notes que j'avais prises pour me rappeler des contraintes importantes.
Il y a en particulier le barré, les tableaux, et la gestion des listes pour lesquelles je dois être vigilant.

La commande utilisée est

pandoc --from dokuwiki --to XXX moto.txt --output moto.md

Avec XXX selon :

1. Le markdown_strict ajoute des espaces surprenants dans les listes entre le tiret initial et le texte.
2. Le markdown_github doit être remplacé par gfm ; les tableaux semblent bien gérés ; mais le barré est géré ~~ plutôt que <s>.
3. Le markdown échappe les guillemets \' ce qui est surprenant ; y'a des ~~ aussi ; les lignes sont limitées à 72 caractères (ce qui est le cas des 3 précédents d'ailleurs…).
4. Le markdown_mmd a l'air pas mal : on a des <s> pour les barrés, les tableaux sont bien gérés ; les lignes sont tronquées aussi. Mais probablement que cela ne pose pas de soucis dans la conversion ; y'a toujours des espaces inutiles dans les listes.
5. Le commonmark me fait des tableaux avec <td><tr>, y'a des <s>, les limitations de caractères par ligne ; pas d'espaces inutiles dans les listes mais probablement mal indentés.

Tableau récapitulatif

(à lire : https://www.jdbonjour.ch/cours/markdown-pandoc/#extensions-%C3%A0-la-syntaxe-markdown-impl%C3%A9ment%C3%A9es-par-pandoc )

Commentaires

• 10. A signifie qu'une liste a les 9 premiers avec une espace supplémentaire ; c'est à dire commence à 1. A, jusque 9. I puis 10. J (avec une unique espace entre le . et J. cela semble systématique même si la liste fait moins de 10 éléments.

Choix du convertisseur

Au vu du test précédent voici mes commentaires sur chacun des convertisseur : 1. markdown_strict : non à cause des tableaux 2. gfm : non à cause du barré 3. markdown : non à cause du barré (et des apostrophes !) 4. markdown_mmd : oui 👍️ 5. commonmark : non à cause des tableaux

Réflexion sur l'usage de Pelican par rapport à d'autres éditeurs/publicateurs/lecteurs de contenu

Pour du contenu (comprendre « du texte »), il y a deux aspects principaux : écrire et lire. Dans le monde informatique, je vais coreller cela à trois notions : l'édition (pour créer ou modifier), la publication, ceci permettant ensuite la lecture. Voir à ce propos d'ailleurs la notion liée aux bases de données du “CRUD” pour create, read, update, delete. Finalement je les couvre tous avec la notion édition/lecture.

Aujourd'hui, je m'intéresse à Pelican, mais j'ai en parallèle 2 autres outils permettant ces actions. Petit comparatif d'où s'effectue 2 actions importantes : l'édition et la lecture.

Effectivement, avec Pelican seul, je perds l'aspect « édition partout ». Néanmoins je réfléchis à la piste de récupérer certains fichiers Nextcloud au moment de la publication avec Pelican. Évidemment il aurait un choix à faire entre écraser/remplacer un fichier, ou lever une alerte pour amener à comparer les différences (à la manière d'un commit git). Mais c'est une piste à explorer qui pourrait s'avérer fort pertinente pour que Pelican devienne le coffre public d'un certains nombres de mes écrits.

Dernière mise-à-jour : 2024-06-10