En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation – L’Atelier des Savoirs

en fait, je n’utilise pratiquement plus du tout de traitement de texte. Pratiquement que des éditeurs #MarkDown : rapides, légers, efficaces…

Le truc pénible que j’affronte en ce moment, ce sont les différentes syntaxes de type markdown qui existent, du bbcode à mediawiki en passant, donc, par markdown (essentiellement sur les usines git*).

En fait, j’aimerais bien que mediawiki se mette à faire du markdown... ou l’inverse... :-)

sans parler de #SPIP

Trouvé par Sylvain : « Drag and drop tools are just simpler. That’s a fact.

That’s why I’m working on a drag and drop alternative to Microsoft Word. To get started, just open up the dictionary panel, find the word you like and drag it onto the document. »

▻https://twitter.com/markdalgleish/status/1172260389158977536

Pour convertir les dialectes #Markdown entre eux (mais aussi d’autres « formats ») j’utilise #pandoc

Pandoc - About pandoc
▻https://pandoc.org/index.html

If you need to convert files from one markup format into another, pandoc is your swiss-army knife. Pandoc can convert between the following formats:

(← = conversion from; → = conversion to; ↔︎ = conversion from and to)

Well. Je trouve #markdown super ... pour exporter du html. Dès qu’il s’agit d’aller vers d’autres formats, ça demande d’installer tellement de dépendances pour avoir quelque chose de propre (par exemple des images redimensionnées à la taille du fichier d’export) qu’à ce stade, je finis toujours par copier coller dans libreoffice mon document pour pouvoir le transmettre à d’autres. (j’utilise uberwriter, mais c’est vrai aussi pour les autres soft testés (atom...).

@supergeante mais markdown c’est juste pour rédiger l’intérieur des chapitres, forcément ça fait pas tout. Dans l’idée d’un workflow complet du genre Syntaxe légère => web => print, il faut forcément coupler avec d’autres outils, pour contrôler finement les images ou autres choses non texte de ce genre. À priori avec un langage de template qui fait vraiment tout ce qu’il y a « autour » de la transformation pur du texte, càd faire le plan, l’entourage des chapitres, retailler les images, etc.

Nous actuellement on ne fait pas ça avec markdown mais avec SPIP, mais le principe reste le même. Du coup ya la syntaxe légère SPIP, mais aussi les modèles d’insertion d’images aussi. La syntaxe légère est transformée comme pour markdown, mais donc il y a un squelette qui s’occupe de mettre tous les chapitres ensemble et produire le HTML final. Qui ensuite est mis en forme avec une CSS print (avec tous les trucs modernes).

Là on fait tout nous-mêmes, pour tout contrôler, mais on peut très bien imaginer que des outils comme Pandoc ou autre fasse aussi ce travail. Je veux dire, c’est à ce morceau du workflow (après la gestion de la syntaxe légère) de retailler les images, et si ça manque, faut leur demander. :)

– Syntaxe légère, organisé en chapitres (tout dans le même document, ou bien dans plusieurs fichiers, ou comme nous dans une base de données avec nos objets « Chapitres » de SPIP)
– La syntaxe légère est transformée en HTML
– Un autre outil, langage de template ou autre, s’occupe de composer le document complet avec vraiment tout (sommaire, pied de pages, travail des images, etc).
– On a alors un unique HTML complet
– Qui est soit transformé en PDF à partir d’une CSS, soit en ODT, ou autre encore (mais c’est toujours à partir du HTML qui est pivot à priori)

Alors, (presque) tout pareil... sauf que la syntaxe en entrée n’est pas du tout légère : c’est du XML/TEI issu de la numérisation d’ouvrage papier. ▻https://github.com/DrozNumerique/zord-library