La version 1.84 publiée les jours derniers permet désormais, à la demande générale et après deux ans de repoussage-au-lendemain-de-ce-qu'on-peut-faire-le-jour-même, de calculer les différents taux de couverture d'encre nécessaires à l'impression d'un document.
Cette fonctionnalité permet en particulier de facturer l'impression d'une photographie plus cher que l'impression d'un document texte. La fonctionnalité par défaut de pkpgcounter est de compter le nombre de pages dans différents types de documents.
La fonctionnalité qui vient d'être ajoutée permet en outre de calculer pour chaque couleur d'encre dans quatre espaces colorimétriques différents, le pourcentage de chaque page recouvert avec cette couleur particulière. Cette fonctionnalité est un portage et une extension de la même fonctionnalité du logiciel PrintBill (qui semble mort depuis au moins deux ans). Les espaces colorimétriques supportés sont : Noir et Blanc (BW), Rouge/Vert/Bleu (RGB), Cyan/Magenta/Jaune (CMY), et Cyan/Magenta/Jaune/Noir (CMYK).
Les types de fichiers supportés sont :
- PostScript
- PDF
- PCLXL (aka PCL6)
- PCL3/4/5
- DVI
- TIFF
- ESC/P2
- OpenDocument (ISO/IEC DIS 26300)
- Zenographics ZjStream
Cependant le calcul du taux de couverture d'encre pour les trois derniers types de fichiers n'est pas encore supporté, et n'est que partiellement supporté pour le format TIFF. Il est prévu de supporter également les autres types de documents dans un avenir proche, ainsi que si possible le format propriétaire SPL2 dont l'analyse a été publiée récemment ici même.
Aller plus loin
- pkpgcounter (1472 clics)
- Le tarball de la v1.84 (415 clics)
- PyKota (346 clics)
- JASMine (274 clics)
# Impressionnant !
Posté par matthieupoirot . Évalué à 3.
Je vais aborder un point de vue plus mercatique : cela interresserait-il uniquement le milieu des grosses impressions (photocopieurs...) ou tu as deja eu des remarques de la part d'autres type de structure? Y'a vraiment un marché?
[^] # Re: Impressionnant !
Posté par Jerome Alet (site web personnel) . Évalué à 3.
Environ 10% sont des boites informatiques qui servent d'intermédiaires.
Les 10% restant sont des entreprises, souvent très grosses et plutôt de l'industrie (pétrole par ex).
Tout ça à vue de nez.
# Prix
Posté par Matthieu . Évalué à 2.
[^] # Re: Prix
Posté par Jerome Alet (site web personnel) . Évalué à 3.
Comme les cartouches sont vendues avec une durée de vie estimée par exemple à 5000 pages couvertes à 5% (couverture moyenne constatée), tu fais le calcul du coût d'une page à 100%.
Tu multiplie ensuite ce coût par le taux de couverture réel estimé par pkpgcounter, et ce pour chaque couleur, tu ajoute les valeurs, et ça te donne le coût réel de ta page.
# Possible?
Posté par salvaire . Évalué à 2.
1) mes collègues envoient à l'imprimante la plus proche des documents de 200 pages,
2) utilise pas toujours psnup -2 (presbytie?),
2) un mauvais job vide le bac à papier,
3) il faut parfois si prendre en 20 fois avant d'avoir la bonne impression (orientation marge recto-verso ...)
Je me demandais si cela serait possible (avec cups):
- d'avertir l'utilisateur que le job est trop gros pour cette imprimante et par conséquent est redirigé vers une autre imprimante
- que le job pourrait utiliser psnup -2
- voulez vous réellement imprimer 200 pages?
- visualiser le job tel qu'il va -réellement- sortir sur l'imprimante (marge, orientation ...) et pas ce que gv montre à l'écran
- votre job va planter l'interpréteur postscript de l'imprimante et va user 10 ramettes. J'ai déjà eu le coups avec une image corrompue dans un ps: imprimante nb ça passe, couleur ... Régulièrement je vois un paquet de 500 pages couleurs, ou transparent dans la poubelle.
Le dernier point (et le précédant en partie) est très certainement du ressort de l'imprimante, à moins de répertorier les particularités de chaques imprimantes. Il faudrait pouvoir simuler l'imprimante sur l'ordinateur. Mieux utiliser un interpréteur libre sur l'imprimante. Mais faut pas rêver.
Tous ça pour dire les imprimantes c'est bête comme une machine, pas écologique, et ça coûte/rapporte une fortune.
[^] # Re: Possible?
Posté par Jerome Alet (site web personnel) . Évalué à 3.
- Que le job pourrait utiliser psnup -2 : pour l'instant je ne sais pas détecter que le job est ou n'est pas en nup. Si tu sais faire n'hésite pas à me dire comment et j'essaierai d'intégrer cette fonctionnalité.
- demander confirmation : oui, c'est facile.
Les deux derniers points sont effectivement du ressort de l'imprimante à mon avis, encore que j'essaierai de convertir le job en PDF avec ghostscript et le regarderai dans xpdf. S'il n'y a pas eu d'erreur de conversion, l'imprimante le mangera sans doute (???) sans problème.
Dans les lignes ci-dessus quand j'écris "facile" je veux dire facile avec les outils adéquats, je pense notamment à mes logiciels pkpgcounter, Tea4CUPS et PyKotIcon (voir http://www.pykota.com/software)
[^] # Re: Possible?
Posté par salvaire . Évalué à 2.
(hormis ajouter %% psnup dans l'en-tête du postscript)
Ton cerveau identifie une double page par: une page, un blanc, une page.
1) tu coupe les bords long pour supprimer les hauts et pieds de pages généré par a2ps
2) tu projette l'image bitmap (un histogramme) de la première page (ou la somme de plusieurs pages) sur le bord long.
Si tu obtient
_____**********___**********___
0____*________*___*________*___
________________x______________
x = centre
c'est que tu as "deux colonnes"
Tu peut faire la même opération sur le bord court pour vérifier l'assertion que tu as des hauts et des pieds de pages, et une page au milieu.
Sinon comment calcul tu l'encre consommé? En sommant les bitmap pour chaque couleurs? consommation cpu?
[^] # Re: Possible?
Posté par Jerome Alet (site web personnel) . Évalué à 1.
> Sinon comment calcul tu l'encre consommé? En sommant les bitmap pour chaque
> couleurs?
En gros c'est ça. Chaque fichier est tout d'abord transformé en TIFF multipage 24 bits/pixel dans la résolution choisie entre 72 et 1200 dpi (par défaut 72 dpi, plus rapide mais moins précis). Cette transformation est faite par une combinaison de GhostScript, GhostPCL, et dvips selon le type de fichier d'entrée. Ensuite effectivement c'est une simple somme par couleur (sauf pour CMYK où il faut calculer le K en fonction des pixels gris) suivie d'une division.
> consommation cpu?
Grosse.
La transformation en bitmap prend parfois plusieurs étapes, c'est quand même assez lourd surtout si on augmente la résolution, et ensuite le calcul lui-même est fait en Python donc ça va quand même moins vite qu'en C, surtout pour le calcul en CMYK qui est plus complexe que les autres.
[^] # Re: Possible?
Posté par salvaire . Évalué à 2.
Tu pourras jamais rivaliser avec les milliards de neurones du cerveau qui font une analyse contextuelle. Mais un pop-up suggérant à l'utilisateur -non vigilant- d'imprimer deux pages par feuilles serait intéressant pour réduire les coûts (/4 en recto-verso). D'ailleurs la plupart des livres ont un format proche du A5, c'est moins volumineux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.