Word-Anhänge sind entgegen der zwischenzeitlichen Abgesänge –
Nowadays, I get the same feeling of dread when I open an email to see a Microsoft Word document attached. Time and effort are about to be wasted cleaning up someone’s archaic habits. A Word file is the story-fax of the early 21st century: cumbersome, inefficient, and a relic of obsolete assumptions about technology. It’s time to give up on Word.
– und verfrühter Hoffnungen weiterhin eine außerordentlich raumgreifende Geißel der Menschheit. Trotz des Gegenwinds halte ich aber an den textbezogenen Rules for Computing Happiness fest –
- Use a plain text editor that you know well. Not a word processor, a plain text editor.
- Do not use your text editor for tasks other than editing text.
- Keep as much as possible in plain text. Not Word or Pages documents, plain text.
- For tasks that plain text doesn’t fit, store documents in an open standard file format if possible.
– und auch hier erweist sich Pandoc als hilfreich. Mit dem Einsatz von w3m für das inline rendering von HTML-Nachrichten gibt es bereits eine Vorlage für die feindliche Umarmung ungeliebter Anhänge (in diesem Fall Office Open XML Document und Open Document Text):
# .muttrc auto_view application/vnd.openxmlformats-officedocument.wordprocessingml.document application/vnd.oasis.opendocument.text # .mailcap application/vnd.openxmlformats-officedocument.wordprocessingml.document; ~/scripts/view_attachment %s "-" application/vnd.openxmlformats-officedocument.wordprocessingml.document; pandoc --from docx --to markdown; copiousoutput application/vnd.oasis.opendocument.text; ~/scripts/view_attachment %s "-" application/vnd.oasis.opendocument.text; pandoc --from odt --to markdown %s; copiousoutput
Mit dieser Konfiguration erzeugt Pandoc für jedes OOXML- und ODT-Dokument eine Textversion (mit Markdown-Auszeichnungen), die automatisch in der Pager-Ansicht von mutt dargestellt wird. Die Konversion ist allerdings nicht perfekt: Aufzählungen innerhalb einer OOXML-Tabellenzelle werden von Pandoc manchmal ignoriert, und die Kombination unterschiedlicher Pandoc-Versionen sorgt für überraschende Effekte. Eine unter Ubuntu verfügbare Pandoc-Version von 2020 (2.9.2.1) generiert zum Beispiel OOXML-Dokumente, deren Tabellen von LibreOffice und neueren Pandoc-Versionen (2.19+) nicht verstanden werden. Das macht sich bemerkbar, wenn ein aktuelles Pandoc einen OOXML-Anhang rendert, der mit dem älteren Pandoc erstellt wurde – statt wohlgeformter Markdown-Tabellen enthält die Textfassung nichts. Außerdem unterscheidet sich die Darstellung von Überschriften zwischen den Pandoc-Versionen (Setext-style vs. ATX-style). Beide Phänomene sind nur für Menschen relevant, die unterschiedliche Pandoc-Versionen als OOXML-Generator und -Parser einsetzen, und es wäre übertrieben, von einer Breitenwirkung der fehlenden Abwärtskompatibilität zu sprechen.
Bei dieser Gelegenheit fällt mir auf, dass ich bislang auf den Hail Mary-Ansatz zur Identifikation von MIME-Types durch mutt gesetzt habe:
If Mutt can not determine the MIME type by the extension of the file you attach, it will run the command specified in
$mime_type_query_command. If that command is not specified, Mutt will look at the file. If the file is free of binary information, Mutt will assume that the file is plain text, and mark it astext/plain. If the file contains binary information, then Mutt will mark it asapplication/octet-stream.
Ursache der undifferenzierten Typisierung fast aller Anhänge ist die unter macOS fehlende Referenzdatei mime.types. Um dieses Defizit zu beheben, kann man die Datei von einem anderen System kopieren (nach ~/.mime.types oder /etc/mime.types) oder sich das file-Kommando zu Nutze machen:
# .muttrc set mime_type_query_first = yes set mime_type_query_command = "file -b --mime-type"
Der erste Parameter stellt die Präzedenz von file gegenüber mime.types sicher.