Convertir ODT en RTF

RTF a été défini par Microsoft en 1987 et il a été lu par Word, WordPad, OpenOffice, LibreOffice Writer, TextEdit, les traitements de texte embarqués dans les messageries, les éditeurs Markdown, et une longue liste de logiciels qui n’existent plus. C’est le format texte qui s’échange le plus largement, et c’est presque toujours le bon choix quand un destinataire ne précise rien et que la mise en forme doit passer.

L’ODT est plus riche, plus moderne, et incompatible avec tout ce qui n’a pas été mis à jour depuis quinze ans. Pour un ODT qui doit sortir d’un cercle d’utilisateurs avertis, le RTF est le chemin le plus court pour qu’un texte mis en forme arrive lisible. Pour un ODT qui doit être modifié par un relecteur en Word, c’est presque toujours suffisant.

L’ODT vient de Draw ou de Writer, et le RTF est produit par LibreOffice. Aucune représentation intermédiaire ne se glisse : la même base de code lit l’ODT et écrit le RTF, et c’est le même programme qui a défini le format source. C’est le cas le plus favorable qui existe, et l’essentiel de la conversion est transparent pour cette raison.

Pour un ODT produit par Word ou par Google Docs, la conversion est un peu moins directe : LibreOffice lit un format tiers avec ses propres règles d’interprétation, et quelques détails de mise en forme peuvent être différents de l’intention d’origine. La parade est d’utiliser l’ODT tel qu’il a été enregistré par son auteur, et de ne pas modifier en chemin.

Le texte, les styles de paragraphe et de caractère, les tableaux avec leurs cellules fusionnées et leurs bordures, les images ancrées, les en-têtes et pieds de page, les notes de bas de page, les listes numérotées et à puces, la mise en page avec marges, sauts de section, orientation. Pour un document ordinaire, presque tout arrive identique, parce que RTF a été conçu pour transporter tout cela dès 1987.

Les champs — un titre de chapitre généré automatiquement, un numéro de page, une référence croisée — survivent, mais leur comportement peut dépendre du logiciel de lecture. Word les met à jour à l’ouverture, TextEdit les affiche tels quels. Pour un document qui compte sur les champs, ouvrir le RTF dans Word une fois et l’enregistrer à nouveau est la voie la plus sûre.

Ni l’ODT ni le RTF ne contiennent les polices. Le document nomme une police, et le logiciel qui l’ouvre la cherche dans le système, ou la substitue. La conversion ne change pas ce mécanisme : si l’ODT disait Calibri et que Calibri n’est pas sur la machine qui lira le RTF, le RTF dira Calibri aussi, et la substitution se fera à l’ouverture.

Pour un document composé dans une police présente sur la plupart des machines — Times New Roman, Arial, Calibri, les polices Microsoft standard — la conversion est sans impact. Pour une police de design particulière, l’incorporer dans l’ODG avant export ou la convertir en images dans le texte avant export sont les deux voies pour garantir la fidélité.

Les macros LibreOffice Basic n’atteignent jamais le RTF : RTF n’a pas de mécanisme pour embarquer du code exécutable, et aucune conversion ne le fabrique. Le suivi des modifications — marques d’ajout, marques de suppression, commentaires de relecture — est porté dans le RTF, et un logiciel qui le comprend l’affichera comme dans l’ODT.

Pour un document qui fait l’objet d’une revue collaborative, le RTF est un bon véhicule pour les marques de révision, et c’est d’ailleurs un format historiquement utilisé pour cela. Pour un document dont l’automatisation est centrale, la conversion est une perte sèche, et il faut reconstruire la logique dans le programme cible, ce qu’aucun convertisseur ne peut faire à la place de l’utilisateur.

Les images ancrées arrivent dans le RTF, et leur qualité ne change pas. Les objets OLE — un tableau Excel embarqué, un schéma Visio, une équation — survivent dans le RTF, et un logiciel qui sait les rendre les affichera ; Word les montre, TextEdit affiche une icône et un nom. C’est une dégradation pour un document qui en porte beaucoup, et c’est sans changement pour un document qui n’en porte pas.

Pour un ODT qui contient une équation Writer, le RTF la porte comme un objet OLE plutôt que comme un objet MathML. Word et WordPad lisent cette forme ; d’autres logiciels affichent une icône sans le contenu. Pour un texte qui doit être lisible partout, exporter l’équation en image avant la conversion est la voie la plus sûre.

Les en-têtes et pieds de page sont portés, et la pagination suit. Les sauts de section — qui produisent souvent un changement d’orientation, de marges ou de format de numérotation — sont portés aussi, et c’est précieux pour un document qui change de format en cours de route. La conversion n’a pas à inventer ces éléments : ils existent dans l’ODT, et le RTF les accepte.

Pour un document de plusieurs sections — page de titre sans numéro, corps en chiffres arabes, annexes en chiffres romains — la sortie est presque toujours lisible sans intervention. Pour un document qui utilise des sections pour positionner des images ou pour des effets de mise en page complexes, un coup d’œil dans Word avant livraison permet de vérifier que la pagination est celle attendue.

La conversion passe par un conteneur LibreOffice sur notre infrastructure, et le conteneur ne peut pas atteindre l’internet. Le fichier arrive, est traité, et le répertoire temporaire est supprimé à la fin, dans un bloc qui s’exécute aussi en cas d’erreur. Le quota journalier limite à 100 le nombre de conversions par visiteur et par jour, ce qui est une protection contre l’abus plutôt qu’une contrainte pratique.

Pour un document qui contient des éléments sous embargo — un contrat en négociation, un mémoire non publié, un rapport interne — c’est la forme de conversion qui ne crée pas de copie persistante. La taille maximale acceptée par la version gratuite est 25 Mo par fichier, ce qui est la limite du conteneur et qui couvre largement la plupart des ODT du quotidien.

RTF utilise un système d’échappement Unicode qui représente tout caractère en quatre chiffres hexadécimaux précédés d’un antislash et d’une apostrophe : `\'e9` pour le `é`, `\'fc` pour le `ü`, `\'4e2d` pour le `中`. Cette représentation survit à un changement d’encodage du fichier en cours de transport, et un RTF contenant du cyrillique, du grec, du japonais ou de l’arabe reste lisible sur une machine qui n’a pas la police en question, parce que la valeur Unicode est portée par l’échappement et non par un encodage de bytes.

Pour un document qui mélange plusieurs écritures — un rapport multilingue, un texte traduit, un jeu de données avec des commentaires dans plusieurs langues — le RTF est l’un des rares formats de texte enrichi qui ne perd pas d’information dans le transport, et c’est la raison pour laquelle il reste utilisé dans les échanges juridiques et universitaires plus de trente ans après sa définition. C’est aussi ce qui rend le format précieux pour des textes qui doivent être signés ou relus, parce qu’une signature numérique apposée sur le RTF reste valide tant que le contenu textuel n’est pas modifié, et c’est une propriété que peu d’autres formats de texte enrichi partagent.