In my opinion, we should drop the PDF composition and support, and only work through LibreOffice. The PDF composition is hard to maintain and update. In addition to use LibreOffice templating, we could remove the document specific generation and create output documents only based on templates, so a single engine (ok, i agree, we could do this now with PDF, but this is less easier). Another benefit is we simply could generate non-pdf documents, and eventually also replace Excel/CSV generation tool.
The fact systems don't have OO libs is a low problem, because the generation is server-side (or the local engine is used to render ODT template ? i don't believe). The fact we would have to maintain it is similar to what is actually done with the PDF libraries: we running a defined version of this tool, and compatibility with higher version is low in the priority as long as we can run the actual one. Question is, embeding the ODT/ODS engine is doable ?? This is eventually something i could code this summer. Le 27/02/2012 15:18, Régis Houssin a écrit : > hi, > > all systems have no openoffice library. Must remain compatible with the > largest number of system. > > > Le 27/02/12 15:14, [email protected] a écrit : >> Hi >> >> I'm not sure to all understand but why don't use OOo/LibreOffice >> templating and do an uuconv plugin to translate them in pdf ? >> I'll be easier to separate presentation functionnality to others part. >> >> Km >> >> _______________________________________________ >> Dolibarr-dev mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> > > Cordialement,
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
