[Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

Hi,

this is a follow-up to the discussion I had with you about the direct
discovery of IPP printers via Bonjour by the new GTK print dialog and
how the dialog submits jobs to these printers.

First, as I said, the job needs to get spooled somehow, so that it does
not block the client app in case of a large job or the printer suddenly
not continuing to take data (paper out, disappearing on network, ...).
Preferably this should be done by CUPS (creating a temporary queue) so
that the user can control the job (hold, cancel, ...) by the system's
job viewer.

On the other side, not every user is allowed to create CUPS queues,
meaning that for these printers to work generally, the dialog would need
to spool by itself, meaning that the job does not appear in the job
viewer and the user has the hassle of different methods of controlling
his print jobs.

Probably the best way is really the system service cups-browsed for
discovering, setting up, and taking down Bonjour/IPP network printers
then, and not the dialog ...

But the good side of the discovery of IPP printers via the print dialog
is that one does not need PPD files. cups-browsed has to generate a PPD
file to make the print dialog list the options of the CUPS queue
genberated by cups-browsed.

Mike, WDYT? As I understand all this, local spooling is needed for every
Bonjour-discovered IPP printer as it can suddenly disappear or stop
taking data. Am I right? So if the dialog sends jobs directly to a
remote printer/print server, it can easily block. Is this correct?

Marek, another important thing: To do IPP printer discovery and polling
capabilities from IPP printers correctly, the PWG has created the "Best
Practices" document:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-bestp10-20130513-rev.pdf

This gives valuable hints, especially for getting the correct option set
and to handle conflicts of the option settings.

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On May 16, 2013, at 12:48 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> Probably the best way is really the system service cups-browsed for
> discovering, setting up, and taking down Bonjour/IPP network printers
> then, and not the dialog ...

cups-browsed is an interesting stop-gap solution, but I really, *really* don't think you want to be doing what you are doing - resolving a printer will wake it up.  Doing it on every computer will cause a LOT of network traffic and generally NOT provide a good user experience.

> ...
> Mike, WDYT? As I understand all this, local spooling is needed for every
> Bonjour-discovered IPP printer as it can suddenly disappear or stop
> taking data. Am I right? So if the dialog sends jobs directly to a
> remote printer/print server, it can easily block. Is this correct?

You need some sort of local spooling, but it need not be cupsd doing the spooling. Consider writing a small DBUS-based spooler that provides UI for monitoring and canceling the job.  This spooler could also handle the basic conversion from PDF to PWG Raster and could despool to cupsd or direct to a printer.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 05/17/2013 07:32 AM, Michael Sweet wrote:
> 
> cups-browsed is an interesting stop-gap solution, but I really, *really* don't think you want to be doing what you are doing - resolving a printer will wake it up.  Doing it on every computer will cause a LOT of network traffic and generally NOT provide a good user experience.
> 

What cups-browsed is doing is as soon as avahi-daemon reports an IPP
printer check whether it is a CUPS queue or a network printer and in the
case of a network printer do a get-printer-attributes IPP request. This
does not wake up my printers out of sleep mode. The printers tested here are

- HP Officejet Pro 8500 A910
- HP LaserJet P3005
- HP Color LaserJet CM3530 MFP

Also the printers get polled only once, not repeatedly, either when
cups-browsed starts or when the printer is turned on.

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On 2013-05-17, at 12:21 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 05/17/2013 07:32 AM, Michael Sweet wrote:
>> 
>> cups-browsed is an interesting stop-gap solution, but I really, *really* don't think you want to be doing what you are doing - resolving a printer will wake it up.  Doing it on every computer will cause a LOT of network traffic and generally NOT provide a good user experience.
>> 
> 
> What cups-browsed is doing is as soon as avahi-daemon reports an IPP
> printer check whether it is a CUPS queue or a network printer and in the
> case of a network printer do a get-printer-attributes IPP request. This
> does not wake up my printers out of sleep mode.

Till, you haven't tested enough printers.  But ALL of the printers below *do* wake up, just not visibly.  Resolving and sending IPP requests to the printer requires that its marking engine components be powered up at some level in order to report media load status, etc.  The vendors are getting better about this, but if you tested against large office printers you would see pretty quickly that the power usage spikes.


> The printers tested here are
> 
> - HP Officejet Pro 8500 A910
> - HP LaserJet P3005
> - HP Color LaserJet CM3530 MFP
> 
> Also the printers get polled only once, not repeatedly, either when
> cups-browsed starts or when the printer is turned on.

FOR EVERY COMPUTER.  Not a big deal at home.  A very big deal in a company or school.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[James Cloos]

>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:

MS> FOR EVERY COMPUTER.  Not a big deal at home.
MS> A very big deal in a company or school.

Then those should use a central cups box (or perhaps a pair) which talk
to the printers, and to which the cups clients on every other box talk.

Forcing the use of dbus to print is wrong.

(*Forcing* dbus is wrong for just about everything. ;^)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

James,

On 2013-05-18, at 7:45 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:
> 
> MS> FOR EVERY COMPUTER.  Not a big deal at home.
> MS> A very big deal in a company or school.
> 
> Then those should use a central cups box (or perhaps a pair) which talk
> to the printers, and to which the cups clients on every other box talk.

But that still requires that cups-browsed not be running and auto-adding printers.

> Forcing the use of dbus to print is wrong.
> 
> (*Forcing* dbus is wrong for just about everything. ;^)


The reason I mention DBUS is that it a simple way to implement a per-user spooler that provides "temporary" print queues.  This could also be part of cupsd (it used to be for CUPS browsing), but I want to be careful not to re-introduce the problems of CUPS browsing.

The key is that auto-adding every printer you see has a huge overhead and isn't particularly useful for the user when there are more than a few printers - how many printers does one user print to in the typical case?  Browsing and adding-on-first-use is a much better solution since then you just manage those printers you use on a particular system.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 05/19/2013 08:08 AM, Michael Sweet wrote:
> 
> The reason I mention DBUS is that it a simple way to implement a per-user spooler that provides "temporary" print queues.  This could also be part of cupsd (it used to be for CUPS browsing), but I want to be careful not to re-introduce the problems of CUPS browsing.
> 
> The key is that auto-adding every printer you see has a huge overhead and isn't particularly useful for the user when there are more than a few printers - how many printers does one user print to in the typical case?  Browsing and adding-on-first-use is a much better solution since then you just manage those printers you use on a particular system.

What about cups-browsed offering a D-Bus service to create a temporary
print queue, queue creation being triggered when a Bonjour-discovered
network printer is selected in the print dialog and "Print" is selected.
Queues are removed if they stay for a time X without job (preferred), on
another D-Bus command, or on shutdown of cups-browsed. These queues get
visible for other users, but this is no problem if they look the same in
the other user's print dialog then. The job of the other user gets into
the same temporary queue then and correctly waits until the first user's
job finishes.

This would make all print spooling be done by CUPS and not require any
extra per-user or per-dialog spooler. Also if different users send jobs
shortly one after the other, the jobs get correctly queued and cannot
mix up.

WDYT?

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

This would be a fine solution until cupsd (or some standard intermediary) does it.

The DBUS service would need to be a system-level service (root or a user account in one of the CUPS system groups) in order for it to auto-add/remove queues, but otherwise it would do the trick.


On 2013-06-12, at 6:52 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:

> On 05/19/2013 08:08 AM, Michael Sweet wrote:
>> 
>> The reason I mention DBUS is that it a simple way to implement a per-user spooler that provides "temporary" print queues.  This could also be part of cupsd (it used to be for CUPS browsing), but I want to be careful not to re-introduce the problems of CUPS browsing.
>> 
>> The key is that auto-adding every printer you see has a huge overhead and isn't particularly useful for the user when there are more than a few printers - how many printers does one user print to in the typical case?  Browsing and adding-on-first-use is a much better solution since then you just manage those printers you use on a particular system.
> 
> What about cups-browsed offering a D-Bus service to create a temporary
> print queue, queue creation being triggered when a Bonjour-discovered
> network printer is selected in the print dialog and "Print" is selected.
> Queues are removed if they stay for a time X without job (preferred), on
> another D-Bus command, or on shutdown of cups-browsed. These queues get
> visible for other users, but this is no problem if they look the same in
> the other user's print dialog then. The job of the other user gets into
> the same temporary queue then and correctly waits until the first user's
> job finishes.
> 
> This would make all print spooling be done by CUPS and not require any
> extra per-user or per-dialog spooler. Also if different users send jobs
> shortly one after the other, the jobs get correctly queued and cannot
> mix up.
> 
> WDYT?
> 
>   Till
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Thu, 2013-05-16 at 22:32 -0700, Michael Sweet wrote:
> You need some sort of local spooling, but it need not be cupsd doing
> the spooling. Consider writing a small DBUS-based spooler that
> provides UI for monitoring and canceling the job.  This spooler could
> also handle the basic conversion from PDF to PWG Raster and could
> despool to cupsd or direct to a printer.

This, in fact, was almost precisely the plan for the "printservice"
project, currently stalled. :-(

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Tim,

On 2013-05-17, at 3:02 AM, Tim Waugh <twaugh@redhat.com> wrote:
> On Thu, 2013-05-16 at 22:32 -0700, Michael Sweet wrote:
>> You need some sort of local spooling, but it need not be cupsd doing
>> the spooling. Consider writing a small DBUS-based spooler that
>> provides UI for monitoring and canceling the job.  This spooler could
>> also handle the basic conversion from PDF to PWG Raster and could
>> despool to cupsd or direct to a printer.
> 
> This, in fact, was almost precisely the plan for the "printservice"
> project, currently stalled. :-(


:(  This was also my advice at the last OpenPrinting summit, and is potentially a future direction of CUPS itself (with different RPC transports on different platforms).

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 05/17/2013 07:32 AM, Michael Sweet wrote:
> You need some sort of local spooling, but it need not be cupsd doing the spooling. Consider writing a small DBUS-based spooler that provides UI for monitoring and canceling the job.  This spooler could also handle the basic conversion from PDF to PWG Raster and could despool to cupsd or direct to a printer.

This would mean to resemble large parts of CUPS (spooling, filtering,
but not networking) for a per-user/per-app printing system, needing a
lot of maintenance/development man power, and extra resources on mobile
devices.

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On 2013-06-13, at 6:01 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 05/17/2013 07:32 AM, Michael Sweet wrote:
>> You need some sort of local spooling, but it need not be cupsd doing the spooling. Consider writing a small DBUS-based spooler that provides UI for monitoring and canceling the job.  This spooler could also handle the basic conversion from PDF to PWG Raster and could despool to cupsd or direct to a printer.
> 
> This would mean to resemble large parts of CUPS (spooling, filtering,
> but not networking) for a per-user/per-app printing system, needing a
> lot of maintenance/development man power, and extra resources on mobile
> devices.


One of the things I'll be working on post-1.7 is a generic IPP service API that can be used to implement custom spoolers, lightweight print services on NAS boxes, etc. The same API could be used as the basis of a user session print service that interfaces directly with IPP printers and talks to a local cupsd for USB and other legacy queues, or to (for example) implement a service on top of, say, Gutenprint to provide an IPP Everywhere gateway to raster drivers (one possible post-PPD future).

The key is re-use of the core CUPS bits (we've already had a lot of success with that at Apple) and abstracting away the common service/spooler aspects so that the only maintenance you have is for the small bits of glue code you use.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 06/13/2013 01:25 PM, Michael Sweet wrote:
> One of the things I'll be working on post-1.7 is a generic IPP service API that can be used to implement custom spoolers, lightweight print services on NAS boxes, etc. The same API could be used as the basis of a user session print service that interfaces directly with IPP printers and talks to a local cupsd for USB and other legacy queues, or to (for example) implement a service on top of, say, Gutenprint to provide an IPP Everywhere gateway to raster drivers (one possible post-PPD future).
> 
> The key is re-use of the core CUPS bits (we've already had a lot of success with that at Apple) and abstracting away the common service/spooler aspects so that the only maintenance you have is for the small bits of glue code you use.

This is a great idea which was really missing, having the daemon's
functionality in a library and letting the developer costumize a
printing system concept as needed. In which time frame will this be
done? 1.8? Summer 2014?

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On 2013-06-13, at 10:34 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> This is a great idea which was really missing, having the daemon's
> functionality in a library and letting the developer costumize a
> printing system concept as needed. In which time frame will this be
> done? 1.8? Summer 2014?


I'll paraphrase the slide from my CUPS Plenary last month: nothing is set in stone or scheduled until we release CUPS 1.7.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Thu, 2013-06-13 at 12:01 +0200, Till Kamppeter wrote:
> This would mean to resemble large parts of CUPS (spooling, filtering,
> but not networking) for a per-user/per-app printing system

My idea (printservice) for this was:
1. Avoid spooling altogether, just send job direct to network queue
(this is often another spooler in any case)
2. Avoid most filtering by requiring jobs to be application/pdf and
requiring that allowable network queues support application/pdf.

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 06/13/2013 01:42 PM, Tim Waugh wrote:
> On Thu, 2013-06-13 at 12:01 +0200, Till Kamppeter wrote:
>> This would mean to resemble large parts of CUPS (spooling, filtering,
>> but not networking) for a per-user/per-app printing system
> 
> My idea (printservice) for this was:
> 1. Avoid spooling altogether, just send job direct to network queue
> (this is often another spooler in any case)

Should be the case for laser printers with built-in network connection,
I don't know how it is with inkjets. Or does IPP Everywhere also require
spooling space inside the printer?

> 2. Avoid most filtering by requiring jobs to be application/pdf and
> requiring that allowable network queues support application/pdf.
> 

As IPP Everywhere has only PWG Raster as required format (the others are
optional), we need at least a pdftoraster filter, but this one filter is
already much better than having device-specific drivers and data fo
1000s of printers.

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On 2013-06-13, at 8:20 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 06/13/2013 01:42 PM, Tim Waugh wrote:
>> On Thu, 2013-06-13 at 12:01 +0200, Till Kamppeter wrote:
>>> This would mean to resemble large parts of CUPS (spooling, filtering,
>>> but not networking) for a per-user/per-app printing system
>> 
>> My idea (printservice) for this was:
>> 1. Avoid spooling altogether, just send job direct to network queue
>> (this is often another spooler in any case)
> 
> Should be the case for laser printers with built-in network connection,
> I don't know how it is with inkjets. Or does IPP Everywhere also require
> spooling space inside the printer?

IPP Everywhere doesn't require that a printer supports spooling.  In fact, the basic support level is a non-spooling raster-only printer.

And since most IPP Everywhere printers will likely fall into the "raster-only" bucket for the foreseeable future, we do need some sort of a client spooling/conversion capability, in addition to basic job management.

>> 2. Avoid most filtering by requiring jobs to be application/pdf and
>> requiring that allowable network queues support application/pdf.
>> 
> 
> As IPP Everywhere has only PWG Raster as required format (the others are
> optional), we need at least a pdftoraster filter, but this one filter is
> already much better than having device-specific drivers and data fo
> 1000s of printers.

Agreed.

Also, even when printing to a PDF filter you may need to do some client-side prep for things like number-up.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Marek,

On 2013-05-17, at 6:07 AM, Marek Kasik <mkasik@redhat.com> wrote:
> ...
> 
> thank you for your suggestions. I'll think about the best solution of
> the spooling problem. I'll also look at the problem Mike talked about
> (the waking up of printers during resolving).


WRT waking up printers, it isn't generally an issue for a print dialog - there you can browse and query TXT records (if needed/desired) without waking the printer up.  Just hold off on doing a Get-Printer-Attributes request until you need it (after printer selection, on bring-up of the dialog for the default printer, etc.)

Also, CUPS 1.6 and later have CUPS APIs for efficiently browsing for and getting printer capabilities.  I don't know what your requirements are for CUPS versions, but that would save a lot of code right there...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 05/17/2013 04:23 PM, Michael Sweet wrote:

> WRT waking up printers, it isn't generally an issue for a print dialog - there you can browse and query TXT records (if needed/desired) without waking the printer up.  Just hold off on doing a Get-Printer-Attributes request until you need it (after printer selection, on bring-up of the dialog for the default printer, etc.)
> 
> Also, CUPS 1.6 and later have CUPS APIs for efficiently browsing for and getting printer capabilities.  I don't know what your requirements are for CUPS versions, but that would save a lot of code right there...

I can perhaps make cups-browsed only poll the printers when they appear
(and then they are recently turned on and awake anyway), by caching the
PPD when the printer disappears (this way also saving system default
changes of the options) before the queue gets removed and when the
printer appears again creating it with the cached PPD (assuming that the
capabilities of a printer do not change during its lifetime).

This way there is no flood of printer wakeups when one boots the machine
and cups-browsed starts or when one arrives with a mobile device with
running cups-browsed in the local network.

So usually only new machines cause printer wakeups.

Only the TXT record does not give enough capabilities to generate a
usable PPD for a CUPS queue.

If I create a raw CUPS queue, can I send a job to it with special IPP
attributes so that CUPS applies a filter chain? This way I could make
cups-browsed only create raw queues to avoit IPP polling and the dialog
then could poll the printer's capabilities when the User selects the
printer, create the option panel PPD-less and send the job with IPP
attributes for the options and for making CUPS applying filters to get
the output into the format needed by the printer.

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

During the discussion I asked this:

On 05/18/2013 08:29 AM, Michael Sweet wrote:
>> If I create a raw CUPS queue, can I send a job to it with special IPP
>> attributes so that CUPS applies a filter chain? This way I could make
>> cups-browsed only create raw queues to avoit IPP polling and the dialog
>> then could poll the printer's capabilities when the User selects the
>> printer, create the option panel PPD-less and send the job with IPP
>> attributes for the options and for making CUPS applying filters to get
>> the output into the format needed by the printer.
>> 

Is this possible with CUPS?

Then CUPS could work as spooler and filter when the exact printer
capabilities are only discovered at the moment when the user selects the
printer for a job via the print dialog. cups-browsed creates only a raw
queue on the Bonjour discovery of a printer to avoid waking up the
printer and complete capabilities are polled via IPP only if the user
selects a printer in the dialog and the dialog has to show the option panel.

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On 2013-06-13, at 6:11 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> During the discussion I asked this:
> 
> On 05/18/2013 08:29 AM, Michael Sweet wrote:
>>> If I create a raw CUPS queue, can I send a job to it with special IPP
>>> attributes so that CUPS applies a filter chain? This way I could make
>>> cups-browsed only create raw queues to avoit IPP polling and the dialog
>>> then could poll the printer's capabilities when the User selects the
>>> printer, create the option panel PPD-less and send the job with IPP
>>> attributes for the options and for making CUPS applying filters to get
>>> the output into the format needed by the printer.
>>> 
> 
> Is this possible with CUPS?


The issue here is that the other end will need to support the file formats and options you are passing.  If you supply a local PPD then cupsd will convert into a format that the other end can handle.

I have some thoughts about how we can support transient queues in cupsd, e.g. send a print request to the local cupsd with the printer-uri of the remote IPP printer, which then causes the creation of a temporary queue and subsequent query of the remote printer's capabilities, etc.  This might be exposed as a persistent "transient" printer ("ipp://localhost/printers/_transient"?) with the client supplying the output-device and output-device-uri in the print request (output-device is already part of IPP, output-device-uri would be an extension) which would automatically "add" the corresponding output device.

I might also bring back "discovered" queues in cupsd, just implemented differently so that we don't wake the printer up until somebody asks for the specific attributes or PPD for a given queue.  That would have the nice side-benefit of existing cupsGetDests clients getting the Bonjour queues as well as offering integrated IPP Everywhere support.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 06/13/2013 01:39 PM, Michael Sweet wrote:
> 
> The issue here is that the other end will need to support the file formats and options you are passing.  If you supply a local PPD then cupsd will convert into a format that the other end can handle.
> 

Here one could easily restrict the support to printers with standard
PDLs so that a handful of filters is enough. Then one sends always PDF
and tell by IPP attributes which output format and which option
settings. So what one needs is the right IPP attributes to tell CUPS the
output format (instead of needing it hard-coded in a PPD).

Would be great if CUPS is capable of this, but if not, I have an idea.
One would need a pdftoany filter which calls first pdftopdf (if pdftopdf
is installed, we could leave it out on mobile) and then one of
pdftoraster+rastertopwg, pdftops, nothing, gstopxl,
pdftoraster+rastertopcl, depending on what output format was requested
by an option (IPP attribute). Problem is how to make the queue using
this filter without having a PPD with hard-coded paper sizes (perhaps
System V interface script?).

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On 2013-06-13, at 8:49 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 06/13/2013 01:39 PM, Michael Sweet wrote:
>> 
>> The issue here is that the other end will need to support the file formats and options you are passing.  If you supply a local PPD then cupsd will convert into a format that the other end can handle.
>> 
> 
> Here one could easily restrict the support to printers with standard
> PDLs so that a handful of filters is enough. Then one sends always PDF
> and tell by IPP attributes which output format and which option
> settings. So what one needs is the right IPP attributes to tell CUPS the
> output format (instead of needing it hard-coded in a PPD).
> 
> Would be great if CUPS is capable of this, but if not, I have an idea.

Current CUPS doesn't support this, but I *do* have code that already does this in other shipping software.  One of the goals of post-1.7 is to explicitly support this kind of configuration, without PPDs (although we will likely generate PPDs for legacy applications for at least a little while yet...)

> One would need a pdftoany filter which calls first pdftopdf (if pdftopdf
> is installed, we could leave it out on mobile) and then one of
> pdftoraster+rastertopwg, pdftops, nothing, gstopxl,
> pdftoraster+rastertopcl, depending on what output format was requested
> by an option (IPP attribute). Problem is how to make the queue using
> this filter without having a PPD with hard-coded paper sizes (perhaps
> System V interface script?).

One of my interests in MuPDF is the ability to create just such a filter in code. And to make it clear, my focus is on using MuPDF to support IPP Everywhere (PWG Raster and PDF) printers - legacy printers can continue to use the old PPD-based driver approach or whatever we come up with in the future (i.e. that "Driver as an IPP Everywhere service" approach I mentioned in a previous email...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Till Kamppeter]

On 05/17/2013 04:23 PM, Michael Sweet wrote:
> Also, CUPS 1.6 and later have CUPS APIs for efficiently browsing for and getting printer capabilities.  I don't know what your requirements are for CUPS versions, but that would save a lot of code right there...

I have looked into the new APIs of CUPS 1.7.x and for example for
getting the possible/available paper sizes of a printer and IPP request
takes place. This still needs waking up the printer.

   Till

Re: [Printing-architecture] Some suggestions for the DNS-SD (Bonjour) printer support in the dialog

[Michael Sweet]

Till,

On 2013-06-13, at 5:58 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 05/17/2013 04:23 PM, Michael Sweet wrote:
>> Also, CUPS 1.6 and later have CUPS APIs for efficiently browsing for and getting printer capabilities.  I don't know what your requirements are for CUPS versions, but that would save a lot of code right there...
> 
> I have looked into the new APIs of CUPS 1.7.x and for example for
> getting the possible/available paper sizes of a printer and IPP request
> takes place. This still needs waking up the printer.

Indeed, but that doesn't happen until you ask for the information, which is presumably after the user has selected the printer and intents to use it...  We never fetch the information for a browsed printer until it is actually "used".

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair