Je vous pose la question pour savoir si ça aurait un intérêt de proposer un service de conversion en ligne avec un module dolibarr qui automatiserait tout ça … ainsi vous si vous ne pouvez pas avoir libreoffice sur votre serveur vous installeriez ce module, ajoutez l’adresse du serveur de conversion et zouuu (ce service pouvant être proposé par votre hébergeur ou en tant que service payant vu que ça consomme des ressources) ?
En vérité je suis en train de finaliser ce service pour nos besoins internes et je me demande si pourrait rendre service de le proposer à n’importe quel utilisateur/trice de dolibarr ?
en fait justement ça pourrait expliquer le faible taux d’utilisation de la fonctionnalité concernant les odt : c’est compliqué d’en générer des pdf pour des utilisateurs « normaux » donc tout le monde « reste » sur les pdf générés nativement par php …
si on rends la transformation odt vers pdf « facile » ça apportera peut-être une plus grande adhésion à cette manière de générer les pdf, je n’en ai aucune idée d’ou ma question
et d’une manière plus « stratégique / vision à moyen - long terme », la lib php qui permet de générer du pdf est plus que vieillissante, les devs un peu à l’arrêt et il serait pas totalement idiot (enfin comme c’est mon avis forcément je trouve que c’est pas idiot hahahah) de prospecter dans des directions pour voir …
@Beers tiens nous au courant, c’est important de faire des retex sur les différentes pistes … pour ce qui est de typst il faudra voir ce que ça donnera comme contrainte de déploiement …
Je suis le seul non développeurs du fil mais utilisateur avancé. Faire un ODT n’est pas très compliqué mais demande un peu de pratique de la patience et donc du temps ce qui n’est pas la première richesse des entrepreneurs. Cela dit ça pourrait se corriger avec un bon tuto ou une amélioration du wiki.
En revanche, le passage au pdf reste le partie la plus compliquée, c’est une usine à gaz surtout quand tu es hébergé et j’ai vite laissé tomber car de toutes façons les modèles pdf sont très beaux et on peut facilement ajouter des mentions manquantes dans les notes ou le pied de page.
Merci pour ton investissement
@ +
Edit : ton module pourrait marcher notamment pour les documents qui n’ont pas de modèle (utilisateurpar exemple) ou très spécifiques comme les expéditions ou les mentions sont propres à chaque entreprise et mode de transport (VL, PL, interne, externe, avion, train, international etc)
C’est pile poil la raison d’être du dev que je suis en train de faire, j’ai des documents à générer pour des « objets » dolibarr qui n’ont pas de modèles natifs … et surtout pour des objets générés par le module builder !
Bonjour
Je pense qu’un des freins est effectivement la difficulté/impossibilité de mettre libre Office sur tous les serveurs
Certes les modèles pdf d’origine peuvent satisfaire un grand nombre…
Oui il existe aussi des modules comme Infras, Rubis, Ultimate qui permettent déjà d’aller plus loin…
Et oui il existe aussi des cas où (n’étant pas assez calé en PHP) il est possible de prendre le temps de faire l’odt qui va bien, avec des spécificités
Donc je pense qu’un module comme celui proposé pourrait intéresser du monde
Tout dépend évidemment du coût à l’usage, mais @erics n’est généralement pas trop gourmand
très intéressant ton idée, j’ai fait de l’odt to pdf y a pas longtemps, et effectivement pas simple d’utilisation pour un néophyte et surtout en fonction de l’hébergement comme le dit @FlorianResasco.
De mon expérience, ce qu’il manque dans l’odt au pdf, c’est que je peux pas utiliser la fonction native de dolibarr pour faire signer mon nouveau fichier… tu crois que c’est possible avec ton développement ? car la coté pertinence on est pas mal, je fais mon contrat avec mon client en ODT et on peut le signer à la dolibarr en signature dématérialisée… tu en penses quoi ?
j’en pense que c’est tout à fait possible car a la fin de la génération du pdf via le module dolipdf il suffit de lancer le hook afterPDFCreation (ce que je vais faire si ce n’est déjà fait) … ce qui fait que facturx peut le prendre en charge par exemple pour rajouter le xml dans la facture issue d’un modèle odt …
et ensuite comme c’est un pdf normal module comme (au pif) uptosign peut lancer la signature
Personnellement, j’aurais beaucoup d’utilité à une telle fonction.
Actuellement, il y a deux freins pour moi à l’utilisation des odt :
cette conversion en pdt (qui pourrait être réglée par votre projet)
l’établissement des modèles au format odt
Alors si tout cela devenait plus facile, j’en aurais beaucoup d’utilité pour mon activité.
A mes débuts avec Dolibarr, j’ai tenté d’utiliser les odt pour créer mes propres documents. J’ai renoncé en raison de la complexité. Je pense que beaucoup d’utilisateurs du même niveau que moi en arrivent à la même conclusion.
Pour les documents standard de Dolibarr, j’ai trouvé des modules qui me permettent de les personnaliser selon mes besoins. Le besoin de modèles odt ne se fait donc pas sentit.
Pour des besoins particuliers non couverts par les modèles standard de Dolibarr, je mets encore des odt en place. C’est alors vraiment un cauchemar. Sur le papier, cela semble si simple, mais dans la réalité, c’est complexe et très chronophage :
problème de copier/coller (même en sachant comment faire ces fameux copier/coller) je ne crois pas avoir réussi à mettre en place un document odt sans faire un test de fonctionnement après l’insertion de chaque variable. J’ai identifié que ce sont surtout la mise en forme des caractères ou bien la création de conditions qui posent problème
problème de variables odt, qui dans certains modules, ne sont pas substituées
problème de la mise en place des tableaux : tout simplement, je n’y arrive pas, et ce n’est pas faute d’avoir lu le wiki.
Je précise que j’ai acheté extraodt. Malgré quelques fonctionnalités bien pratiques, cela ne m’a pas permis de contourner toutes mes difficultés liées aux modèles odt. Notamment, je n’arrive pas à utiliser le fichier testODTtag.odt et à savoir quelles variables sont disponibles.
Pour conclure, un serveur disponible pour la conversion serait un réel plus. Je veux bien tester le serveur !
Bonjour,
J’avais touché un peu et même détourné la fonctionnalité pour un module de fusion de document.
J’ai maintenant abandonné.
Comme je suis sur un poste individuel, le souci n’est pas libreoffice.
Pour moi, le souci vient du module de fusion lui-même. Même si on respecte la syntaxe, il arrive des cas où les champs ne sont pas reconnus. Il faut effacer et recommencer la saisie du champ. La faute à des éléments insérés dans le document xml et non visibles.
De plus, je n’étais jamais arrivé à faire les boucles sur les lignes.
Pour moi, ce module est et restera bancale (oups, je suis sévère). L’idée du Markdown est bien plus porteuse, à mon sens.
Voici un exemple d’une appli toute neuve qui fait de la fusion à base de markdown : https://helificus.forge.apps.education.fr/
J’ai commencé quelques modèles de documents odt qui seront livrés à côté du module avec une liste pour que tout utilisateur puisse aller « piocher » les documents en fonction de ses envies.
Pour l’instant histoire de rester « conforme » j’ai fait deux modèles de factures pour voir, les résultats sont intéressants
Sur le lien des exemples j’ai ajouté hier soir (tard) un exemple de projet avec table des matières, logo d’entreprise et une « forme » un peu plus proche de ce que je « livre » à mes clients histoire de creuser quelques pistes …
Concrètement, pour donner une idée des difficultés des odt pour un utilisateur lambda.
Test du modèle template_project.odt livré avec Dolibarr. La présentation en tableaux fonctionne, mais pas la présentation en listes. Rien n’est substitué. Si même le modèle Dolibarr ne fonctionne pas, c’est dire !
Autre difficulté, le simple fait de supprimer des rubriques du modèle en « vicie » le fonctionnement.
Toujours avec template_project.odt. J’ai simplement et « proprement » supprimé toutes les pages pour ne conserver que les deux dernières (rubrique « Lines of tasks »). Absolument rien n’a été modifié dans ce qui a été conservé.
Si je génère mon odt, j’ai un message d’erreur
« ‹ projectfiles › segment not found in the document. The tag [!-- BEGIN xxx --] or [!-- END xxx --] is not present into content file. »
Tiens, je ne suis pas la seule… (mais la solution ne semble pas marcher avec mon fichier)
Je n’ai jamais dit que c’était simple mais par contre c’est une alternative intéressante aux fichiers natifs et surtout ça permet de faire des documents non prévus par les modèles natifs.
Les messages d’erreurs sont à améliorer grandement, par exemple moi qui suis développeur je sais quoi faire de « projectfiles segment not found in the document » … il manque dans le fichier odt un bloc concernant le mot clé « projectfiles » … il doit y être, même « vide » mais il doit être présent.
C’est sans doute une piste d’amélioration significative du moteur d’export odt : si un bloc n’existe pas hé bien on passe à la suite au lieu de refuser de faire le fichier … enfin ça serait mon approche, je ne vois pas pourquoi un « bloc » serait indispensable à la génération du fichier …
Ensuite pour ce qui est des modèles « livrés » qui ne marchent pas ma fois ce sont des bugs et je pense qu’en fait le passage par les odt est « un parent pauvre » de dolibarr … ma manière de voir est qu’il y a la un champ d’amélioration significatif et qu’il suffit de se retrousser les manches (et de trouver des $$$ pour le temps à y consacrer). pour paraphraser un slogan d’une marque de « sport » mais version développeurs « just code it »
C’est pile poil la raison d’être du dev que je suis en train de faire, j’ai des documents à générer pour des « objets » dolibarr qui n’ont pas de modèles natifs … et surtout pour des objets générés par le module builder !
