[gull] CUPS : Utilisation de gs très lente sur ARM

[Félix Hauri]

On Sat, Apr 21, 2012 at 08:43:01AM +0200, François Bianco wrote:
> Bonjour,
> 
> J'ai un boîtier ARM sur mon réseau qui fait serveur d'impression sous Debian. 
> Il a le problème malheureux que lorsqu'on imprime directement sur l'imprimante 
> partagée par CUPS, il prend des lustres pour imprimer. Je peux désormais 
> mettre la faute sur l'utilisation de gosthscript pour convertir les documents. 
> Le temps de calcul de conversion peut monter à la minute par page, pas du tout 
> acceptable.
:->>

Tu aurrais pu donner une estimation, (par exemple en milli-secondes, comme pour
 http://fr.wikipedia.org/wiki/IP_over_Avian_Carriers#L.27ex.C3.A9cution_du_ping
;), pour qu'on se rende compte...


> Mes questions d'ignorant sur le fonctionnement de CUPS et des impression : 
> est-il possible de ne pas utiliser gs ? ou est-il possible de dédier cette 
> tâche aux client qui sont bien plus puissant en calcul ?
Oui

> mais faire un by-pass de gs pour ajouter l'option NOINTERPOLATE ne donne rien, 
> toujours aussi lent.
Meuh!? Je pense qu'il doit y avoir une différence... du genre 20' par pages au
lieu de 25... ou quelque chose comme ça...

> Je précise que l'imprimante est une HP Officejet Pro L7500 que j'ai fais 
> tourner avec HPCUPS ou HPLIP, même comportement, toujours un petit gs avant 
> d'imprimer.
En fait, tu devrais faire tourner ces outils sur une machine qui dispose
de ressources en mémoire *et* en CPU:

 Pour exemple, une page A4 à 600 DPI, en couleur (24bits):

 page A4 (en mm):
   $ echo 'x=sqrt(sqrt(2))*250;x;x/sqrt(2)' | bc -l
       297.30177875068026667750
       210.22410381342863575670
 en pouces (DPI = Dip Per Inches) : /25.4
   $ echo 'x=sqrt(sqrt(2))*250/25.4;x;x/sqrt(2)' | bc -l
       11.70479443900316010541
        8.27653952021372581719
 à 600 DPI, cela fait:
   $ echo 'x=sqrt(sqrt(2))*250/25.4*600;x;x/sqrt(2)' | bc -l
       7022.87666340189606324600
       4965.92371212823549031446
 soit une surface de
   $ echo 'x=sqrt(sqrt(2))*250/25.4*600;x*x/sqrt(2)' | bc -l
       34875069.75013950027858213301 
 pixels, à raison de 3 octet par pixel (24bits):
   $ echo 'x=sqrt(sqrt(2))*250/25.4*600;x*x/sqrt(2)/1024^2*3' | bc -l
       99.77837491075372775625
 'faut compter bosser sur 100Mibi pour en venir à bout.

Sans parler des machine mathématiques complexes qui sont mise en oeuvre
par le traitement postscript.

Pour info, un RIP Postscript (c'est ce que tu essaie de faire avec ton ARM)
est une machine vendue dans le monde pro (imprimeurs, graphistes) entre
1'500 et 150'000 CHF.

Bref, ce n'est pas un job pour un machine ``à faible consommation''.

> Merci d'avance pour vos pistes de recherche.
. Sur ton ARM: Cups doit pouvoir imprimer directement les ``raw''.
  (au pire: suppression de CUPS au profit de LPR/BSD)

. Sur *tes* clients, *ton* imprimante doit y être configurée pour effectuer
  le traitement des données localements et envoyer le données d'imprimantes
  (brute, raw, data, binaires, propriétaires...) vers ton ARM.
  càd: les logiciels HPCUPS et/ou HPLIP doivent y être installés et la
  détections de l'imprimante ne se faisent probablement pas de manière
  adéquate, la config devra être effectuées ``à la main''.

. voire éventuellement du coté de Samba, il y a une méthode pour présenter
  une imprimante (LPR/BSD) *avec* les drivers adéquats. Peut-être que, dans
  le forums, quelqu'un aurra proposé une solution pour forcer la config et
  l'envoi de flux binaires (raw ou data, données brutes...)
  (n'aborder cette étape/aspect qu'après avoir réussi et compris l'étape 2;)

Bonne chance!

(Penses à nous rapporter tes succès;)

--
 Félix Hauri  -  <felix at f-hauri.ch>  -  http://www.f-hauri.ch