[cups.development] How to best implement fax sending using a multi-function printer?

Tim Waugh twaugh at redhat.com
Fri Jul 2 07:36:16 PDT 2010


On Fri, 2010-07-02 at 05:49 -0700, Reinhold Kainhofer wrote:
> The hpfax backend seems to rely on an additional application being
> manually started (hp-sendfax) before printing to the fax printer in
> CUPS, which I regard as highly user-unfriendly. The hpfax backend then
> communicates with hp-sendfax via dbus, and hp-sendfax does all the
> communication with the printer.

Note that the hplip solution can only ever work when the multifunction
printer is directly connected to the machine you submit the print job
from, as D-Bus is a local-only protocol.

> I don't like both approaches, to be honest. In particular, since all
> you need to do is send the above PJL commands to the printer, it would
> make much more sense to let the ordinary http/ipp/... backends to the
> job and obtain the phone number before. So, again, what is the easiest
> way to request the phone number from the user?

The way the SAMBA backend gets additional information it needs is by
using the auth-info-required attribute.  The way it works is as follows:

When the backend starts, if it does not have all the information it
needs, it writes out 'ATTR: auth-info-required="username,password"' or
something similar, and exits with a special exit code
CUPS_BACKEND_AUTH_REQUIRED. (Once this happens, CUPS remembers that two
auth-info values are required and rejects future jobs that do not
provide them.)

If the user is running system-config-printer-applet in their desktop, or
another similar program, it will spot this stopped job and present a
dialog to the user asking for the additional required information.  Once
it has it, the job is restarted using the CUPS_AUTHENTICATE_JOB IPP
operation, providing an auth-info attribute containing the requested
values.

It seems to me that this system could be used for collecting fax
numbers.  The only wrinkle is that it is specific to the *backends* --
filters don't get to request auth-info.  And after all, there is nothing
specific to a particular transport method about setting some PJL
options.

Perhaps an alternative scheme would be to have a filter that requires a
particular IPP attribute for the fax number -- I'm not sure if a
suitable attribute is already defined.  The print dialog user interfaces
would need to be changed in this case, and there is also the problem of
how the filter should behave if that attribute is not provided.

I'd love to see a general solution to this problem...

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cups.org/pipermail/cups/attachments/20100702/dd384e62/attachment.bin>


More information about the cups mailing list