gimp-print-devel

[Gimp-print-devel] escputil needs to be adapted to CUPS

[Till K. <til...@gm...>]

Hi,

see

https://bugs.launchpad.net/ubuntu/+source/gutenprint/+bug/134784

and other bug reports linked there.

CUPS uses exclusively device names based on make and model, escputil 
uses exclusively raw device file names. This leads to the case that GUI 
frontends are not able any more to simply derive the correct escputil 
command line for a printer for which there is a CUPS queue.

It would be great if escputil could also be called with the printer 
being specified based on make and model, for example by a call with the 
CUPS URI on the command line.

    Till

Re: [Gimp-print-devel] escputil needs to be adapted to CUPS

[Tim W. <tw...@re...>]

On Mon, 2007-08-27 at 15:00 +0100, Till Kamppeter wrote:
> It would be great if escputil could also be called with the printer=20
> being specified based on make and model, for example by a call with the=20
> CUPS URI on the command line.

It would be even better if it could be made to work as a CUPS 'COMMAND'
filter, and respond to a CUPS-COMMAND file by setting the CUPS device
attributes for ink level.

But is that too optimistic?

Tim.
*/

Re: [Gimp-print-devel] escputil needs to be adapted to CUPS

[Robert L K. <rl...@al...>]

   From: Tim Waugh <tw...@re...>
   Date: Tue, 28 Aug 2007 10:45:22 +0100

   On Mon, 2007-08-27 at 15:00 +0100, Till Kamppeter wrote:
   > It would be great if escputil could also be called with the printer=20
   > being specified based on make and model, for example by a call with the=20
   > CUPS URI on the command line.

Actually, it can be, via the -m flag (although it's not the CUPS URI
in that case, but the driver or printer name).  The problem is that
some of the subcommands require direct access to the printer -- in
particular the status, identify, ink, and extended ink commands.

   It would be even better if it could be made to work as a CUPS
   'COMMAND' filter, and respond to a CUPS-COMMAND file by setting the
   CUPS device attributes for ink level.

   But is that too optimistic?

Dunno -- I don't know just what's involved here.

Re: [Gimp-print-devel] escputil needs to be adapted to CUPS

[Tim W. <tw...@re...>]

On Tue, 2007-08-28 at 07:05 -0400, Robert L Krawitz wrote:
> From: Tim Waugh <tw...@re...>
>    Date: Tue, 28 Aug 2007 10:45:22 +0100
> 
>    On Mon, 2007-08-27 at 15:00 +0100, Till Kamppeter wrote:
>    > It would be great if escputil could also be called with the printer=20
>    > being specified based on make and model, for example by a call with the=20
>    > CUPS URI on the command line.
> 
> Actually, it can be, via the -m flag (although it's not the CUPS URI
> in that case, but the driver or printer name).  The problem is that
> some of the subcommands require direct access to the printer -- in
> particular the status, identify, ink, and extended ink commands.

My particular interest here is in getting fine-grained ink-level
reporting working using the gutenprint native CUPS driver.

A program like escputil can still run in a CUPS filter.  The CUPS
backend, which actually opens the raw file, relays data from the raw
device back through the pipeline in known file descriptor (I think it's
3).

>    It would be even better if it could be made to work as a CUPS
>    'COMMAND' filter, and respond to a CUPS-COMMAND file by setting the
>    CUPS device attributes for ink level.
> 
>    But is that too optimistic?
> 
> Dunno -- I don't know just what's involved here.

I think what's involved is making escputil available for use by the
commandtoepson/commandtocanon CUPS filters.  This means either making
escputil usable in library form, or making escputil take an option to
run in CUPS filter mode.

The basic idea is that instead of one read-write file descriptor, you
have two file descriptors: STDOUT_FILENO for writing to the device, and
3 for reading from it.  In libcups there is a helper function,
cupsBackChannelRead(), for reading from the input file descriptor, but
it's probably as easy to just use file descriptor 3.

One escputil is callable in this way, it should be called by
commandtoepson/commandtocanon if the command is "ReportLevels".

Reporting the results is done by writing special "ATTR:" and "STATE:"
lines to stderr, in a similar way to the current "ERROR:" and "INFO:"
lines.

The STATE: lines adjust the printer state reasons.  CUPS maintains a
list of named "state reasons" for each printer, such as "media-empty",
"marker-support-low". "offline" etc (these are defined in the IPP
specification).  We can set and unset these using STATE: output lines.
To add a state reason to the set, output:

"STATE: +marker-supply-low-warning\n"

To remove it, output:

"STATE: -marker-supply-low-warning\n"

That's fairly course-grained information.  The ATTR: lines allow us to
say more precisely what the ink levels are.  The keywords available for
this are:

* marker-colors
  This is a comma-separated list of #RRGGBB colours.

* marker-levels
  This is a comma-separated list of percentages 0-100.

* marker-names
  This is a comma-separated list of supply names such as "cyan"

* marker-types
  This is a comma-separated list of keywords describing the type of
supply, e.g. "inkCartridge" (see RFC 3805).

So I think we'd want something like:

ATTR: marker-types=inkCartridge,inkCartridge,inkCartridge,inkCartridge
ATTR: marker-names=cyan,magenta,yellow,black
ATTR: marker-levels=70,30,80,20
ATTR: marker-colors=#aaffff,#ff33aa,#ffff33,#000000

Tim.
*/

Re: [Gimp-print-devel] escputil needs to be adapted to CUPS

[Gene H. <gen...@ve...>]

On Wednesday 27 February 2008, Tim Waugh wrote:

Not per sei related to cups, but has everyone now forgotten about mtink?

Nice gui, and supports the epsons I own at least.

>On Tue, 2007-08-28 at 07:05 -0400, Robert L Krawitz wrote:
>> From: Tim Waugh <tw...@re...>
>>    Date: Tue, 28 Aug 2007 10:45:22 +0100
>>
>>    On Mon, 2007-08-27 at 15:00 +0100, Till Kamppeter wrote:
>>    > It would be great if escputil could also be called with the
>>    > printer=20 being specified based on make and model, for example by a
>>    > call with the=20 CUPS URI on the command line.
>>
>> Actually, it can be, via the -m flag (although it's not the CUPS URI
>> in that case, but the driver or printer name).  The problem is that
>> some of the subcommands require direct access to the printer -- in
>> particular the status, identify, ink, and extended ink commands.
>
>My particular interest here is in getting fine-grained ink-level
>reporting working using the gutenprint native CUPS driver.
>
>A program like escputil can still run in a CUPS filter.  The CUPS
>backend, which actually opens the raw file, relays data from the raw
>device back through the pipeline in known file descriptor (I think it's
>3).
>
>>    It would be even better if it could be made to work as a CUPS
>>    'COMMAND' filter, and respond to a CUPS-COMMAND file by setting the
>>    CUPS device attributes for ink level.
>>
>>    But is that too optimistic?
>>
>> Dunno -- I don't know just what's involved here.
>
>I think what's involved is making escputil available for use by the
>commandtoepson/commandtocanon CUPS filters.  This means either making
>escputil usable in library form, or making escputil take an option to
>run in CUPS filter mode.
>
>The basic idea is that instead of one read-write file descriptor, you
>have two file descriptors: STDOUT_FILENO for writing to the device, and
>3 for reading from it.  In libcups there is a helper function,
>cupsBackChannelRead(), for reading from the input file descriptor, but
>it's probably as easy to just use file descriptor 3.
>
>One escputil is callable in this way, it should be called by
>commandtoepson/commandtocanon if the command is "ReportLevels".
>
>Reporting the results is done by writing special "ATTR:" and "STATE:"
>lines to stderr, in a similar way to the current "ERROR:" and "INFO:"
>lines.
>
>The STATE: lines adjust the printer state reasons.  CUPS maintains a
>list of named "state reasons" for each printer, such as "media-empty",
>"marker-support-low". "offline" etc (these are defined in the IPP
>specification).  We can set and unset these using STATE: output lines.
>To add a state reason to the set, output:
>
>"STATE: +marker-supply-low-warning\n"
>
>To remove it, output:
>
>"STATE: -marker-supply-low-warning\n"
>
>That's fairly course-grained information.  The ATTR: lines allow us to
>say more precisely what the ink levels are.  The keywords available for
>this are:
>
>* marker-colors
>  This is a comma-separated list of #RRGGBB colours.
>
>* marker-levels
>  This is a comma-separated list of percentages 0-100.
>
>* marker-names
>  This is a comma-separated list of supply names such as "cyan"
>
>* marker-types
>  This is a comma-separated list of keywords describing the type of
>supply, e.g. "inkCartridge" (see RFC 3805).
>
>So I think we'd want something like:
>
>ATTR: marker-types=inkCartridge,inkCartridge,inkCartridge,inkCartridge
>ATTR: marker-names=cyan,magenta,yellow,black
>ATTR: marker-levels=70,30,80,20
>ATTR: marker-colors=#aaffff,#ff33aa,#ffff33,#000000
>
>Tim.
>*/



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Wilner's Observation:
	All conversations with a potato should be conducted in private.

Re: [Gimp-print-devel] escputil needs to be adapted to CUPS

[Tim W. <tw...@re...>]

On Wed, 2008-02-27 at 10:42 -0500, Gene Heskett wrote:
> Not per sei related to cups, but has everyone now forgotten about mtink?
> 
> Nice gui, and supports the epsons I own at least.

What would be really useful is to have ink-level detection right in the
normal printing tool chain: this allows CUPS on the local machine to get
told of the ink levels, which allows the information to be propagated to
remote clients, who can then use a standard graphical interface for all
model types.

It's great that there are applications with nice interfaces now, but it
would be better to have one interface to this information.

Tim.
*/

Re: [Gimp-print-devel] escputil needs to be adapted to CUPS

[Michael R S. <ms...@ap...>]

Tim Waugh wrote:
> On Wed, 2008-02-27 at 10:42 -0500, Gene Heskett wrote:
>> Not per sei related to cups, but has everyone now forgotten about mtink?
>>
>> Nice gui, and supports the epsons I own at least.
> 
> What would be really useful is to have ink-level detection right in the
> normal printing tool chain: this allows CUPS on the local machine to get
> told of the ink levels, which allows the information to be propagated to
> remote clients, who can then use a standard graphical interface for all
> model types.
> 
> It's great that there are applications with nice interfaces now, but it
> would be better to have one interface to this information.

Current CUPS 1.3.x supports the marker-* attributes for ink levels,
and CUPS 1.4.x will have built-in support for SNMP and 1284-based
ink level reporting.

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer

Re: [Gimp-print-devel] escputil needs to be adapted to CUPS

[Gene H. <gen...@ve...>]

On Wednesday 27 February 2008, Tim Waugh wrote:
>On Wed, 2008-02-27 at 10:42 -0500, Gene Heskett wrote:
>> Not per sei related to cups, but has everyone now forgotten about mtink?
>>
>> Nice gui, and supports the epsons I own at least.
>
>What would be really useful is to have ink-level detection right in the
>normal printing tool chain: this allows CUPS on the local machine to get
>told of the ink levels, which allows the information to be propagated to
>remote clients, who can then use a standard graphical interface for all
>model types.
>
>It's great that there are applications with nice interfaces now, but it
>would be better to have one interface to this information.
>
>Tim.
>*/

While it may be that there are more than just epsons that either can service, 
escp2util was originally built for epsons. I just checked mtink perfs, and it 
is limited to epson only.  And it apparently, unless you build from srcs 
which I have in the past but not for F8, does not have a man page, so I've 
NDI if it can be redirected to write a CSL text file which could be passed 
back to cups and parsed to show a real time ink level at 
localhost:631/printers.  That would be a nice feature.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Open Standars, Open Documents, and Open Source"

  -- Scott Bradner (Open Sources, 1999 O'Reilly and Associates)