Articles précédents : Logiciel
- [35] Qui va remplacer SysVinit ?
- [63] Premiers pilotes libres pour les imprimantes Samsung
- [16] Beagle 0.2.8 : prise en charge de Thunderbird
- [7] Une plateforme Web créant des sites dynamiques
- [14] Bygfoot en version 2.0
- [0] Cultuzz offre son moteur de réservation Cultbooking en Open Source
- [2] Nouvelle version de K3DSurf, le modeleur de surfaces mathématiques
- [57] ShaKe, un défragmenteur pour GNU/Linux
- [39] Hachoir, le couteau suisse qui découpe vos fichiers binaires
- [3] NERO 1.01 disponible pour GNU/Linux
Liens connexes
- pkpgcounter (620 hits)
- Le tarball de la v1.84 (169 hits)
- PyKota (208 hits)
- JASMine (214 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : pkpgcounter v1.84 supporte le calcul du taux de couverture d'encre
Posté par Jerome Alet (page perso, ). Modéré le 29 août 2006.
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.
![[en]](../../../images/en.png)
pkpgcounter (620 hits)-
Le tarball de la v1.84 (169 hits)
-
PyKota (208 hits)
-
JASMine (214 hits)
> Lire la suite (9 commentaires, moyenne: 2,3). [dépêche : 1250 caractères]
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.
Impressionnant !
Je suis vraiment admiratif du travail fait ; il fallait reussir à le faire, mais surtout il fallait y penser!
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 (page perso, ) le 30/08/2006 à 08:32. (lien). Évalué à 3.En fait environ 80% des utilisateurs de mes logiciels qui tournent autour des quotas d'impression sont des universités, lycées et autres écoles.
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
Va maintenant falloir estimer le prix d'une micro-goutte d'encre !
-
[^]Re: Prix
Posté par Jerome Alet (page perso, ) le 30/08/2006 à 09:29. (lien). Évalué à 3.Sans aller aussi loin, il te suffit de connaitre le coût d'une page recouverte à 100% d'une couleur.
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?
Je constate régulièrement que,
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 (page perso, ) le 31/08/2006 à 08:53. (lien). Évalué à 3.- Avertir que le job est trop gros et va être rerouté : oui, c'est facile.
- 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 () le 31/08/2006 à 18:06. (lien). Évalué à 2.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é.
Mon intuition pour psnup -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 (page perso, ) le 31/08/2006 à 21:39. (lien). Évalué à 1.Je n'ai pas tout compris mais ta méthode semble intéressante. Cependant comment alors différencier d'un document qui aurait réellement 2 colonnes ?
> 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 () le 01/09/2006 à 12:56. (lien). Évalué à 2.Pour être plus précis: au lieu de compter les pixels noirs, tu compte le nombre de pixels dans chaque lignes et chaque colonnes (projection). Après tu fais des suppositions sur les symétries, les blancs et sur la taille des pages (A5). Pour améliorer la fiabilité de la méthode, au lieu de raisonner sur une page pleine de blanc, tu peux superposer plusieurs pages, ainsi que les pages miroir. Évidement c'est pas fiable à 100%, par exemple deux page A5 paysage avec en-tête et pied de page sur une page A4 correspond à 3 blanc intérieurs. Je pense aussi à des transparents pleins de blancs. Par contre une mise en page sur deux colonnes ne correspond pas à du A5. Il faut faire des essais.
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.
-
-
-
Cette page a été générée par Templeet en 0.0882s (dont 0.0216 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.