[Dolibarr-bugtrack] [bug #21120] collisions de champs dans pdf de propale azur/ Pourquoi pas OOO?

[bugdolibarr]

URL:
  <http://savannah.nongnu.org/bugs/?21120>

                 Summary: collisions de champs dans pdf de propale azur/
Pourquoi pas OOO?
                 Project: Dolibarr
            Submitted by: jlem
            Submitted on: mercredi 19.09.2007 à 08:21
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None
        Operating System: None

    _______________________________________________________

Details:

Bonjour
dans
http://localhost/dolibarr/htdocs/admin/company.php

Si la raison sociale de l'entreprise
est trop long, les champs de la boite bleue pale 
de la propale azur se chevauchent.

Suggestion: 
Pour information, j'ai developpé dans le passé un  
logiciel en mode web PHP/Mysql generant des 
contrats d'assurance en .doc et .pdf, 
dont les textes, les champs et les parametres sont assez longs, compliqués,
avec insertions de clauses conditionnelles ,
calculs très  personnalisés  , etc...
De plus, le client demandais que les contrats puissent 
être modifiés a posteriori sous Word bien sur!
(un process, pourquoi pas, mais alors souple, hein!)

Je disposais pour ce faire d'un referenciel de contrats ".doc" paramétrés
en publipostage sous Word, utilisés habituellement par le client avec une
table Excel.

Désirant ne pas changer le process du client à ce niveau pour ne pas
risquer de dégrader le caractère juridique de ses contrats, 
j'ai eu l'idée d'utiliser OpenOffice en back-end du site web , pour 
générer les contrats finaux PDF et Word sans modifier sa collection de
".doc".

Il faut pour cela avoir la possibilité bien sur d'installer openoffice sur
le mm serveur que dolibarr (quoique cela pourrait être fait en distant via un
ssh) et de l'appeler depuis
un script PHP, avec une macro paramétrée réalisant le publipostage, la
génération PDF et Word. Pour éviter l'affichage de OOO sur un vrai X-window
il est possible d'utiliser un dumb X server (sous Linux) qui ne mobilise
aucune interface graphique et permet donc à OOO de tourner en batch. Le
package OOO 2.1 
du site d'origine incluant le JRE a très bien fonctionné.

Certes le prix de l'infrastructure est élévé et pas très portable, mais
cela permet:

- de récupérer des existants déja déclarés conformes à l'usage,

- faciles à modifier et à enrichir par les clients eux-memes dans le monde
bureautique, 

- de gérer la mise en page de manière bcp plus fctionnelle
que l'écriture en PHP qui nécessite une maintenance logicielle
pour finalement modifier du contenu.

Voila l'idée
Merci de votre attention.
JLEM 









    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21120>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/