Bon, ce qui devait m’occuper un petit moment a fini par déborder, déborder, déborder, et par m’occuper près de six mois, avec un premier refactor, puis une réécriture, puis une nouvelle… Ça a été une belle aventure, pleine d’enseignements, riche de doutes et d’insatisfactions…
Mais bon, là, il est grand temps que je partage la chose, étant amené à pouponner d’ici peu
Et donc « L’idée principale derrière cette réécriture de odt2spip est de permettre de bien mieux gérer les styles des fichiers .odt lors de leur import, en cherchant à récupérer les styles personnalisés (définis dans les styles) et les styles automatisés (lorsque l’on crée par exemple un paragraphe intégralement en gras). Cette refonte se veut aussi une occasion d’écrire des tests, afin de s’assurer que de futures évolutions du plugin n’introduisent pas de régressions. »
Personnellement, j’aime bien le fait que odt2spip efface les styles personnels de chacun car ça permet de garder une unité graphique dans le site.
De plus n’y a-t-il pas un risque d’alourdir de façon conséquente le code produit par odt2spip ?
Euh, qu’appelles-tu « styles personnels » ici ? Parce que l’idée c’est de ne retirer que les informations de balisage et de formatage permises par SPIP ou Markdown. Lorsque je parle des styles, ce sont les informations liées à des styles définis dans Libreoffice.
Justement, un-e rédacteur-trice A va définir des styles dans LibreOffice et un-e rédacteur-trice B d’autres styles etc, on risque donc d’avoir une multitude de styles différents d’un article à l’autre, non ?
Mais peut-être n’ai-je pas compris.
Ah, bah dans ce cas-là, oui, tu risques d’avoir du gras là où tu ne veux pas, mais c’est à ton groupe de contributeurs de s’entendre sur un template partagé à mon sens.
J’aurais une question : j’utilise un modèle avec des styles personnalisés en plus des styles standard car un article pour SPIP chez moi a un chapo, un descriptif et peut avoir un PS. Ça n’est, évidemment, pas repris par odt2spip, mais c’est assez pratique : les copier-coller c’est pas fait pour les chiens. Du coup, est-ce que le plugin pourrait mettre en place ces éléments au bon endroit ? Si oui, sur la base de quel style standard ? Je referai mon modèle en fonction au besoin.
Par ailleurs, concernant les images, le plugin ne reprend pas les informations sur les images : titre, alt, descriptif (qui sont « cachés ») seulement les légendes. Est-ce que ça a changé ? Je trouve que ce serait bien pour mieux pousser les personnes à alimenter ces champs.
Un très grand merci pour ce formidable plugin dont je ne peux absolument plus me passer.
PS : comment j’installe cette version sur mes sites ?
Je sais il y a déjà une réponse. Je complète. LibreOffice possède une vaste bibliothèque de styles standard qui ont chacun leur rôle. Ces styles peuvent (doivent) être personnalisés, naturellement. Mais odt2spip s’en fiche puisqu’ils reposent sur une feuille de style : styles.css et que le plugin ne récupère pas cette feuille de style. Sachant qu’on n’emploie pas n’importe quel style pour n’importe quoi derrière il y a de la programmation qui sert à la structure du texte (titre 1, etc.) ou envoie des infos aux dispositifs d’assistance (blocs de citation par exemple).
Ce qu’il faut, en revanche, c’est que les personnes mettent en forme uniquement en utilisant les styles, et les styles standard : il y a des styles pour tout dans LibreOffice. Et le format ODF est basé dès le départ sur la séparation du fond et de la forme, c’est un cousin de l’HTML, puisque c’est fondamentalement du XML.
@Cheguevarine difficile de répondre à toutes ces questions précisément…
Le plugin refactorisé améliore certains points :
il lit désormais les styles définis à la fois dans le fichier styles.xml et dans le fichier content.xml (qui sont des composants en réalité du fichier ont ;
les styles de l’odt ne sont pas tous repris : ne sont conservés que ceux qui sont pertinents pour les syntaxes SPIP ou Markdown ;
sur les images, sont désormais pris en compte les légendes ainsi que le champ alt ;
le plugin n’écrit que deux champs des articles : le Titre et le Texte et ce serait délicat à changer (les champs Chapo ou PS ne sont pas toujours activés notamment)
pour ce qui est de l’installation à ce jour : ces développement sont sur la branche dont le lien a été fourni dans le premier post, le plus simple est donc d’utiliser Git pour faire des tests, sachant que cette version a été faite pour SPIP 5 en cours de développement.
