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
Autour de cette page
Autour de cet article
Weblog
- …
- Joyeuses fêtes
- Motivation et horaires
- Comme le temps passe…
- Évaluation a priori d'une mission
- Du flan, oui mais presque convi
- Circuits fermés
- Autonomie
- SAN : 0
- La machine à voter selon Nat
- …
Derniers commentaires
- Natacha dans Désolarisation
- Natacha dans Ricing
- Damien dans Ricing
- Damien dans Désolarisation
- Damien dans Désolarisation
- Natacha dans Blogoversaire
- Jean Abou Samra dans Blogoversaire
- Jean Abou Samra dans Blogoversaire
- Natacha dans Blogoversaire
- Gro-Tsen dans Blogoversaire
Tags
- (Sans tag) (6)
- Appel au public (17)
- Autoexploration (60)
- BSD (6)
- Boulot (30)
- Création (12)
- En vrac (11)
- Évènement (60)
- Geek (49)
- Goûts (10)
- Humeur (18)
- Inventaire (9)
- Jeux (7)
- Jouets (36)
- Lecture (10)
- Réflexion (23)
- Site (22)
- Social (26)
- Société (14)
- Suite (15)
- Vision atypique (30)
- Vœux (8)
Archives
- 2024 (13)
- 2023 (14)
- 2022 (14)
- 2021 (15)
- 2020 (14)
- 2019 (12)
- 2018 (12)
- 2017 (13)
- 2016 (16)
- 2015 (12)
- 2014 (13)
- 2013 (15)
- 2012 (18)
- Décembre 2012 (2)
- Novembre 2012 (1)
- Septembre 2012 (1)
- Août 2012 (3)
- Juillet 2012 (1)
- Juin 2012 (2)
- Mai 2012 (2)
- Avril 2012 (2)
- Mars 2012 (1)
- Février 2012 (2)
- Janvier 2012 (1)
- 2011 (18)
- 2010 (20)
- 2009 (45)