pkpgcounter v1.84 supporte le calcul du taux de couverture d'encre

Posté par  (site web personnel) . Modéré par Florent Zara.
Étiquettes :
0
29
août
2006
Bureautique
pkpgcounter est un logiciel en ligne de commande permettant d'extraire des informations de différents types de fichiers destinés à l'impression. Ecrit en Python et publié selon les termes de la licence GNU GPL, il est notamment utilisé par les projets PyKota, du même auteur, et JASMine, de Nicolas Costes, mais peut bien sûr être utilisé indépendamment, ou même sous forme de librairie Python.

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

  • # Impressionnant !

    Posté par  . Évalué à 3.

    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  (site web personnel) . É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

    Posté par  . Évalué à 2.

    Va maintenant falloir estimer le prix d'une micro-goutte d'encre !

    • [^] # Re: Prix

      Posté par  (site web personnel) . É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?

    Posté par  . Évalué à 2.

    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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.