Bonjour,
Merci pour cette nouvelle version !
Je viens de charger la version Linux (AppImage), on passe de 190 Mo à 270 Mo. Par curiosité, d’où vient une différence aussi importante ?
Je vais pouvoir tester un peu pendant les vacances…
Et avec un peu de chance faire du ménage sur les issues dans git si cette nouvelle version les corrige 
Passage de la dépendance ffmpeg-ffprobe-static à ffmpeg-static et ffprobe-static pour pouvoir prendre en charge les mac ARM. Le soucis, c’est que ffprobe-static ne s’installe pas aussi bien que ffmpeg-ffprobe-static et embarque des versions compilés de ffprobe pour mac et linux sur mac et linux (donc la moitié des fichiers servent à rien). Un peu du gâchis, et visiblement pas le seul à avoir identifié ce soucis : https://github.com/joshwnj/ffprobe-static/issues/14
Je résoudrai ça pour dodoc 10 
Pas une mauvaise idée ! mais vu que la v10 va tout changer, il va falloir de toute façon faire un gros, gros ménage là-dedans !
Merci pour les explications, je n’avais aucun doute sur la sobriété numérique de do•doc
J’ai creusé la question, c’est embêtant de perdre autant de place (notamment sur un rpi) – on fera mieux pour la v10 !
EDIT : d’ailleurs beaucoup de galères pour installer dodoc (version serveur en ligne et version appli) viennent souvent de dépendances qui ne se préparent pas bien – typiquement ffmpeg et pdf-extractor, le premier utile au montage vidéo et le deuxième à créer des vignettes d’aperçu des PDF envoyé dans la bibliothèque. On pourrait imaginer une version « dodoc light » qui ne contient pas ces paquets ni les fonctionnalités associés, mais qui serait en même temps beaucoup plus légère. Ça aurait du sens @julien (ou d’autres personnes) ?
Pour pdf-extractor et la création de la vignette de PDF, pourquoi pas si on on gagne en poids et qu’on se débarrasse de dépendances qui posent problème pour l’installation. Si l’export en pdf d’une recette page à page fonctionne encore et qu’on remplace par un picto pdf pour identifier le type de fichier je pense que ça fera très bien l’affaire. L’aperçu n’est pas indispensable pour mon usage.
Par contre enlever ffmpeg signifierait l’arrêt d’une bonne partie des recettes et même d’une partie de la capture, non ?
Là ça réduirait énormément les fonctionnalités, donc sur ce point je dirais qu’il est préférable de conserver ffmpeg même si ça complique la tâche.
Oui, j’ai bossé sur cette fonctionnalité pour Corpora et ça fonctionne pas mal dans la version web mais ça se complique quand il s’agit de faire une version appli mac/windows/linux/rpi.
Pour être complet, il faut que je mentionne que la dépendance stl-thumbnailer-node fait aussi partie des dépendances un peu embêtantes, mais on perdrai aussi l’aperçu des fichiers STL et ça commence à faire beaucoup
On verra bien si il faut faire sauter ça.
Oui, bcp de fonctionnalités qui sautent. À priori ça passe sur rpi, mieux que les autres, et pas question d’enlever ça sinon effectivement y a pas mal de recettes qui y passent.
Une autre solution serait d’avoir une version allégée et d’avoir la possibilité d’ajouter des fonctions sous formes d’extensions. Mais il faudrait que ce soit suffisamment simple à installer avec par exemple une fenêtre pour l’admin (gestionnaire d’extensions) où l’on coche les extensions que l’on souhaite ( STL / Réalité augmentée / cartographie…)
Ça permettrait de garder une version simple et légère et de pouvoir l’adapter selon les besoins et utilisations de chacun.
Mais ça complique peut-être beaucoup le développement ?
C’est une bonne idée mais techniquement compliquée – ces dépendances doivent être compilées en natif, et pas sur que ça soit simple à réaliser à la volée. En tout cas sur dodoc 10 il n’y a pas de raisons que la version appli prenne de l’embonpoint, ça ne devrait presque pas bouger. La grosse différence se situera surtout au niveau des données chargées par le navigateur (connexion depuis un autre appareil sur le même réseau ou par internet).