From: Alain COUTHURES (alain.couthures@lafon.fr)
Date: 17/02/2003 - 07:50
Bonjour,
J'ai moi-même mis en service depuis quelques mois une solution d'impression XML->XSL-FO->PDF via MSXML puis FOP.
Toutes mes imprimantes (plus d'une quinzaine; matricielles, jet d'encre et laser) n'étant pas Postscript, j'ai préféré générer un PDF, ce
qui est également bien pratique pour l'archivage, puis faire l'impression du PDF.
Mon serveur est sous Windows 2000 Server et c'est là que les ennuis ont commencé : pour imprimer du PDF, je n'ai trouvé que Acrobat Reader 4
(qui n'est plus supporté...) ou Ghostscript. Le rendu n'est pas identique entre les deux (Acrobat Reader est meilleur) et je n'ai pas trouvé
comment faire comprendre à Ghostcript qu'une imprimante matricielle est sans bords... J'ai donc choisi Acrobat Reader 4 mais sa robustesse
laisse à désirer (plantages, blocages,...) et, par un beau matin, j'en suis venu à avoir systématiquement une attente de plusieurs dizaines
de secondes après chaque impression... ce qui a paralysé le serveur !!!
Ce traitement d'impression a donc été déporté sur un simple PC à côté sous Windows 98 (Acrobat Reader 4 est de la même génération...) en
sérialisant les impressions avec temporisation obligatoire (chacun devant attendre son tour...). Mais là encore, plantages et blocages de
temps en temps et, tout dernièrement, de nouveau des lenteurs insoutenables.
J'en viens à suspecter le nombre d'imprimantes déclarées sur le serveur ou le PC à côté, tout comme les multiples drivers chargés en mémoire
d'être à l'origine de mes malheurs.
Il faut aussi signaler que l'impression à partir d'un serveur n'est pas optimale côté volume de données : il y a presque un rapport de 100
entre le XML des données et les binaires envoyés à l'imprimante par un driver. Dans mes liaisons inter-sites, j'ai des débits d'environ 64K
efficaces (VPN au dessus d'Internet)...
Ma configuration actuelle est la suivante : le serveur copie le PDF dans un répertoire partagé (pas top pour la sécurité...) sur le PC
auquel est raccordé l'imprimante. Ensuite un petit script Windows détecte son arrivée puis lance Acrobat Reader pour l'impression. Pour
l'instant, ça marche...
En cours de développement, j'envisage d'équiper chaque client d'une appli Java pour réceptionner les données XML et appeler uniquement un
FOP retravaillé d'après ses sources pour que l'imprimante puisse être choisie (pas spontané avec Java...). Les feuilles de style sont à
déployer sur les clients (...) et, en plus, il me faut toutes les reprendre car MSXML n'est pas aussi carré que FOP pour les transformations
(pb séparateur décimal, ...) et les polices par défaut (Helvetica,...) n'ont pas la même taille entre FOP et Acrobat Reader !
Voilà comment, d'une solution tout sur le serveur, j'en arrive à une solution distribuée ....
Cordialement,
Alain COUTHURES
LAFON Equipements Pétroliers
Erik Mazoyer a écrit :
> > Pourquoi faire un truc compliqué et contraignant côté client au lieu de
> > faire cela côté serveur? C'est pas un critique négative, mais juste pour
> > comprendre la démarche entreprise.
>
> C'est exactement la question que je me pose.
>
> Faire les traitements coté serveur c'est :
>
> - Réduire les coûts, il suffit d'avoir 1 serveur puissant (les traitements de conversion XSLT et FOP demandent des ressources mémoires).
> - Ne pas avoir de soucis de déploiement.
> - Maîtriser la plateforme de production (le serveur et non tous les clients)
> - Pouvoir mettre en place des caches (pourquoi effectué les calculs chez chaque client alors que le serveur peut le faire qu'une fois)
> - Offrir de nouveaux services,
> - Un seul lieu a maintenir (bug, MAJ, ...)
>
> Cordialement,
>
> --------------------------------------------------------------------
> Erik Mazoyer, Chef de projet
> HyperOffice
> 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex
> Tél. 01 41 96 96 76
> Fax 01 41 96 96 77
> Mél erik.mazoyer@hyperoffice.fr
>
>
> -----Message d'origine-----
> De : Guillaume [mailto:gsouesme@wanadoo.fr]
> Envoyé : vendredi 14 février 2003 16:13
> À : xml-tech Liste
> Objet : [xml-tech] Re: XML > Applet > impression
>
> Le 14/02/03 16:04, « LENTZ Marc » <Marc.LENTZ@ctrceal.caisse-epargne.fr> a
> écrit :
>
> >...
> > l'applet discutera avec l'activex, par javascript ...
>
> Pourquoi faire un truc compliqué et contraignant côté client au lieu de
> faire cela côté serveur? C'est pas un critique négative, mais juste pour
> comprendre la démarche entreprise.
>
> Guillaume
>
> --
> Devenez redacteur <XML>fr et contribuez au developpement du
> xml francophone (http://xmlfr.org/infos/redacteurs/) !
>
> Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
>
> Cette liste est a votre disposition pour discuter en francais de
> tout sujet technique lie a XML.
>
> Pour resilier votre abonnement, envoyez un message contenant
> la commande "unsubscribe" a xml-tech-request@xmlfr.org
> (mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
>
> --
> Devenez redacteur <XML>fr et contribuez au developpement du
> xml francophone (http://xmlfr.org/infos/redacteurs/) !
>
> Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
>
> Cette liste est a votre disposition pour discuter en francais de
> tout sujet technique lie a XML.
>
> Pour resilier votre abonnement, envoyez un message contenant
> la commande "unsubscribe" a xml-tech-request@xmlfr.org
> (mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/06/2004 - 11:06 UTC
webmaster@xmlfr.org
| 
