Du flan, oui mais presque convi

Il y a longtemps, bapt a publié comment faire du flan oui mais convi, c'est-à-dire produire des documents avec le style corporate imposé mais sans perdre sa santé mentale devant Word ou OpenOffice ou LibreOffice.

Je me souviens qu'à l'époque je commençais la rédaction de mon manuscrit de thèse, avec mon éditeur de texte préféré dans un format très sympathique, donc ma réaction à été en gros de le plaindre d'être obligé de produire du « flan » tout en admirant la façon sympathique dont il s'en tirait.

Deux ans et demi plus tard, c'est à mon tour d'être obligée de déjecter des immondices en format Word. Et comme je l'avais écrit dans SAN : 0, c'est tellement insupportable que j'envisageais sérieusement de quitter mon emploi pour échapper à Word, si seulement ça pouvait suffire à y échapper.

Au lieu d'opter pour une solution aussi destructive, j'ai essayé d'y échapper de la même façon que bapt. Dans une certaine mesure j'ai réussi, mais ça s'est beaucoup moins bien passé que son billet laisse croire.

Comme souvent, j'ai eu l'impression que faire les choses proprement et à mon goût c'est comme pratiquer la magie de la Marelle Brisée, il y a toujours un imperfection ou un problème tapis dans l'ombre et prêt à sauter en embuscade pour tout casser et/ou tuer tout espoir.

Matériel de base

Donc pour me mener à bien ma rédaction de documents Word au style corporate, je me retrouve avec mon portable personnel sous FreeBSD, mon poste de travail professionnel sous Windows avec Word 2003, les yeux pour pleurer, et mon dernier point de santé mentale.

Avec mon FreeBSD, j'ai eu recours aux ports suivants :

• textproc/hs-pandoc v1.9.3
• editors/libreoffce v3.5.4
• lang/python27 v2.7.3

Rédiger le contenu des documents

Ça c'est la partie la plus sympathique, en markdown. Et pourtant j'en ai quand même pour 3330 lignes réparties sur trois fichiers source.

De Markdown à OpenDocument

Pour l'instant la procédure de bapt fonctionne très bien. Il y a juste le style de base qui peut être spécifié directement par une option de pandoc plutôt que tripoter directement les archives :

pandoc -f markdown --reference-odt=corpostyle.odt manuel.mkd -o manuel.odt

Comme la contrainte c'est de faire des fichiers Word, et qu'OpenOffice est officiellement interdit au bureau (« parce que ça casse les styles » sic), il aurait été plus immédiat de demander à pandoc de produire des fichires docx plutôt que odt. Hélas, pandoc s'obstine à écrire des fichiers XML invalides dans les archives docx, et je n'ai pas eu le courage de plonger dedans pour comprendre comment une telle aberration est possible.

La référence OpenDocument

J'ai utilisé dans la commande précédente corpostyle.odt sans préciser d'où il sort. Ça a été l'étape la plus pénible de toute la procédure : j'ai coupé le fichier source pour avoir peu de texte tout en gardant au moins une instance de chaque style, et j'ai généré un fichier odt avec la référence par défaut :

pandoc -f markdown manuel-coupe.mkd -o corpostyle.odt

Et ensuite j'ai édité tous les styles avec LibreOffice pour que ça ressemble au maximum aux styles du fichier Word qui m'a servi d'exemple.

Corriger le fichier produit

Aussi incroyable que cela puisse paraître, pandoc ne produit pas un fichier odt directement utilisable.

Le premier problème, que je trouve particulièrement sérieux, est que les images utilisées dans le document ne sont pas listées dans le manifeste, alors qu'elles sont correctement référencées et ajoutées dans l'archive. Donc la première correction est de faire la liste des images et les ajouter au besoin au fichier manifeste (attention aux images issues du style qui y sont déjà).

Le deuxième problème, c'est qu'alors que pandoc utilise bien des styles explicites pour la plupart des objets, les listes sont systématiquement affublées d'un style accidentel, qui a le malheur de ne pas coller du tout avec mon style corporate imposé.

Et il est hors de question que j'ajuste à la main le style de mes 70 listes, donc j'ai étendu mon script qui corrige le manifeste pour qu'il tue aussi tous ces styles accidentels, en les remplaçant par un seul style général. J'ai de la chance, parce que je n'utilise qu'un seul style de listes, sinon une solution aussi simple n'aurait pas été possible.

Le résultat forme le joli script en shell POSIX poétiquement nommé fix-odt.sh.

Écrire un fichier ODF correct

Pour une raison obscure, je n'ai jamais réussi à produire de fichier ODF tout bien comme il faut avec archivers/zip (v3.0). Visiblement LibreOffice tolère bien les fichiers zipés n'importe comment, mais d'autres programmes annexes sont plus pointilleux.

Dans ma procédure finale je n'ai pas eu spécialement besoin de fichiers bien zipés, mais pendant le diagnostic d'un message d'erreur parlant de corruption je suis arrivée à ce script, donc autant le partager, au cas où quelqu'un un jour en ait besoin.

create-odf.py utilise le module python zipfile et construit un fichier ODF reconnu comme valide par tous les programmes avec lesquels j'ai essayé.

Je ne comprends pas très bien ce que zipfile a de plus que archivers/zip. Je sais bien que le fichier mimetype doit être le premier dans l'archive et qu'il ne doit pas être compressé (ce qui est généralement le cas par défaut étant donné sa taille), mais ça ne suffisait pas. Peut-être une version du format de l'archive ?

Arranger le fichier dans LibreOffice

Avec tout ça, je n'ai pas encore fini d'atteindre les limites de pandoc, et la suite n'a pas l'air automatisable en deux coups de cuiller à pot et de shell.

Le style corporate impose une table des matières, que je ne suis pas parvenue à faire créer par pandoc, et qui est bien trop complexe pour être scriptée. Donc il faut cliquer (beurk) dans LibreOffice pour générer une table des matières au format adapté.

De plus, pandoc ne précise pas la taille des images importées, il fait juste un pauv' draw:frame sans attribut de taille. Et à l'ouverture, pour les fichiers wmf, il ne devine pas tout seul la bonne taille, à la place il en fait des carrés de 0.57 cm de côté. Donc il faut parcourir chaque image, clic droit, et rétablir la taille intrinsèque. Heureusement qu'il n'y en a que 7…

Enfin dernier ajustement, LibreOffice a l'air de croire que le titre du document, de style Title sans niveau de plan, doit figurer au premier niveau de la table des matières. J'ai parfois réussi à corriger le souci à ce stade, parfois je l'ai fait à l'étape suivante.

Arranger le fichier dans Word

Comme dit, j'ai droit à Word 2003, et j'ai subrepticement installé le plugin de lecture ODF. J'utilise donc ça pour ouvrir (en lecture seule) le fichier ODF préalablement issu de LibreOffice, et en faire le début de mon document Word à donner aux instances officielles.

Il y a cependant un bon nombre d'ajustements à faire, que je n'ai pas pu faire en amont :

• Les en-têtes du style corporate contiennent le numéro et le texte des deux premiers niveaux de titre en cours, et ces \RefStyle ne passent pas à la conversion, donc il faut les refaire.
• Arranger le style pour le code, parce que manifestement les styles avec bordure passent très mal la conversion.
• La table des matières doit être mise à jour, pour refléter la pagination parfois différente et virer le titre du document si ça n'a pas été possible avant.
• Mettre à jour les propriété du documents (type, version, numéro de projet, etc).
• Ajouter des sauts de section après la première page et après la table des matières, parce que les en-têtes et les pieds de page sont différents.
• Supprimer la liaison entre les en-têtes et pieds de page, pour pouvoir les modifier.
• Effectuer les modifications des en-têtes et pieds de page
• Arranger le texte de la première page.

Envoyer le document aux chefs

Et c'est la que commencent les ennuis. Cette procédure est très pratique, et m'a évité un nombre incroyable de traces de mur sur la tête, mais elle est malheureusement à sens unique. Toutes les modifications ultérieures du document ainsi construit, et toutes les modifications de documents existants, ne semblent pas être possible en dehors du tas d'immondices wordesques.

Du coup je me demande vraiment si tout ça suffira vraiment à me sauver de l'effondrement mental…

(une question alternative est « à combien de personnes va profiter ce billet ? » mais je ne suis pas sûre que la réponse soit plus salvatrice)

Commentaires

1. Le mardi 28 août 2012 à 19:12, par FrnchFrgg :

Je me souviens que dans mes jeunes années d'avant la découverte de TeX j'utilisais Word avec une démarche intransigeante: jamais aucune mise en forme "manuelle" mais seulement affectation de styles et modification des dits styles. Effectivement c'est — avec le recul — quand même fastidieux parce que les styles dans un Word-like sont suffisamment un after-tought pour que Word ajoute de temps en temps des attributs en plus des styles, merdouille dans l'héritage des styles, ou encore choisisse automatiquement un style qui ne convient pas — et le remette régulièrement derrière ton dos.

Un truc particulièrement gênant IIRC c'est que c'est facile d'ajouter des overrides d'un style sur son style de base (genre "Titre1" = "Titre"+Gras) mais c'est souvent difficile voire crânement impossible d'en retirer (passer de "Titre"+Gras+Indent 1cm à "Titre"+Gras). Souvent le mieux qu'on puisse obtenir c'est "Titre"+Gras+Indent x où x est l'indent de "Titre" à ce moment là. Ajoutons à ça que Word a la fâcheuse tendance à sur-spécifier un style (tu modifies un attribut il valide tous les attributs du même onglet) ou à intellisensement "enrichir" tes styles et ça fait un escargot tout chaud^W^W^W beau merdier.

Ce problème est moins flagrant si les styles sont déjà définis, mais là tu tombes sur un autre niveau de problèmes: une hiérarchie de styles écrite par des gens qui ne comprennent pas le principe de la hiérarchie — lire "qui ne savent pas qu'il y en a une" — et a fortiori ne savent pas contourner les idiosyncrasies du système de style Word — lire "qui ne savent pas qu'il y en a" — c'est un merdier sans nom qui va se comporter de manière erratique, genre un titre sur 3 et demi n'a pas la bonne police parce qu'il est précédé d'une liste et qu'il était 2h14 quand le dev de Microsoft est allé pisser.

Et j'en passe pas mal. À noter que (Open|Libre)Office ne fait pas beaucoup mieux, à ceci près que le format étant bien plus sain d'esprit ça diminue d'autant les bizarreries. Par contre la pseudo-intelligence et l'UI prémâchée qui te font des "smart" croche-pieds à tire larigot ça reste.

Ceci étant dit on s'en sort une fois passée la première phase de dépression, en étant très rigoureux et en utilisant les fonctions comme en terrain miné avec le CTRL-Z à la rescousse on peut être relativement efficace. Taper tout au km, faire un beau "supprimer la mise en forme" au cas où et ensuite affecter les styles d'une traite ça m'a plutôt bien réussi...

</logorrhée>

2. Le vendredi 31 août 2012 à 14:16, par Natacha :

Effectivement, il est beaucoup trop fréquent d'ajouter des « overrides » comme tu les appelles, ou « style accidentel » dans mon billet, par analogie aux altérations accidentelles en musique. J'utilise fréquemment les raccourcis Ctrl-Espace et Ctrl-Q (l'un supprime tous les styles de bloc accidentels tandis que l'autre supprime les styles de caractère accidentels, mais j'ai oublié lequel et lequel). Ça ne règle pas l'exemple que tu donnes, vu que ça supprime tout, mais comme il m'est demandé de ne pas en avoir, ça va.

En plus de ces raccourcis, j'utilise énormément le refus de modification de style (qui fait partie de l'immonde système de contrôle de version intégré). Et il m'est plusieurs fois arrivé d'être au bord de l'effondrement lorsqu'un des raccourcis ou un refus ajoute un style accidentel. Ce soft est une horreur sans nom.

Et je suis aussi d'accord avec le fait qu'OpenOffice ou LibreOffice vaut pas mieux, et j'ai le même genre d'incompatibilité majeure avec eux comme avec Word, je l'ai déjà détaillé dans [http://instinctive.eu/weblog/061-zero-point-de-sante-mentale].

Je ne sais pas si c'était volontaire de laisser ton deuxième commentaire en preview sans le poster pour de vrai, alors j'y réponds quand même : indépendemment de la difficulté de faire du .docx valide, il y a quand même un gros problème de base lorsque l'outil n'est pas capable de mettre de l'XML valide dedans. De mémoire c'était une balise fermante d'un parent dans un enfant non-fermé. Un problème grave de génération, quoi.

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.