[Printing-architecture] Printer Application for PostScript printers

[Printing-architecture] Printer Application for PostScript printers

[Till Kamppeter]

Hi,

I have worked towards a PAPPL-based Printer Application for PostScript 
printers, where one usually has a PPD supplied by the printer's 
manufacturer. Many of these you find in foomatic-db on OpenPrinting, but 
in the first approach I only want to consider those without 
"*cupsFilter(2): ..." lines, meaning that these are native PostScript 
PPDs without CUPS or Foomatic extensions.

The code which I have created to implement this is all available in the 
cups-filters package, current state of GIT Master:

https://github.com/OpenPrinting/cups-filters


libppd
------

PPD handling for retro-fitting all kinds of classic drivers is done by 
libppd, all functions from libcups, ppd-private.h added to public API 
ppd.h, source in ppd/ subdirectory. See also

https://github.com/OpenPrinting/cups-filters/blob/master/ppd/README.md

Two functions are added to libppd, to make the creation of Printer 
Applications for retro-fitting classic drivers easier:

'ppdLoadAttributes()' - Load IPP attributes from a PPD file.

This function creates a set of IPP attributes to answer 
get-printer-attributes IPP requests from clients. This function is based 
on load_ppd_attributes() in ippeveprinter from CUPS.

'ppdGetOptions()' - Get the PPD options corresponding to the IPP Job
                     Template attributes for a printer with given PPD and
                     given printer attributes (generated by
                     ppdLoadAttributes()).

This function takes the IPP attributes coming along with a print job and 
converts them into PPD options, so that the correct PostScript snippets 
from the PPD can get inserted. This function is based on get_options() 
in ippeveps from CUPS.


libcupsfilters
--------------

I have started to convert the CUPS filters into functions, the so-called 
filter functions:

https://lists.linuxfoundation.org/pipermail/printing-architecture/2020/003842.html

This way the filters can get easily called as functions, and parameters 
are supplied in a common data structure, data streams are specified by 
file descriptors, and all filter functions have the same argument 
scheme. This allows easy chaining of them (supplying the chain as an 
array of functions would be possible, the chaining filter function I 
have not implemented yet) and generally supplying them as callback 
functions.

Logging is also flexible as the logging is done via a callback function. 
A callback function to use the filter functions in classic CUPS filters 
is supplied as cups_logfunc() in cupsfilters/filter.c.

To start and to support the PostScript Printer Application I have 
converted pstops (from CUPS) and pdftops (from cups-filters). the code 
is in the files cupsfilters/pstops.c and cupsfilters/pdftops.c, the 
headers in cupsfilters/filter.h.

All filter functions will be implemented in the libcupsfilters library.

Later I will add build time options to allow building libcupsfilters 
also without libppd and/or without libqpdf (and then without the filter 
functions needing these libs). This allows to build cups-filters needed 
for the individual Printer Application Snap.

The Printer Application is supposed to take PDF as input format, as this 
is one of the standard formats of driverless printing and also the 
standard format in which CUPS supplies jobs. So one can provide a 
PDF-to-PostScript filter by creating a function calls the pdftops() 
filter function (which in turn calls the pstops() filter function for 
insering the PostScript code of the PPD into the output PostScript 
stream and also adding JCL). Before calling pdftops() this function has 
to call ppdGetOptions() to convert the job's attributes into PPD option 
settings. This function is added to the Printer Application by the 
papplSystemAddMIMEFilter() function of PAPPL.

One could also add a filter for PostScript input which calls only the 
pstops() filter function, but I am in doubt whether there are really 
clients sending PostScript to a Printer Application, CUPS would send 
PDF, and I think iOS clients would also send PDF.

An example for calling a filter function is the filterCUPSWrapper() 
function in cupsfilters/filter.c which allows easy calling of a filter 
function as a classic CUPS filter, see also filter/pdftops.c and 
filter/pstops.c. Another example is the call of pstops() in the 
pdftops() filter function cupsfilters/pdftops.c.



So I have everything to answer a client's get-printer-attributes() IPP 
request and to process a job.

The PostScript Printer Application should have the following properties:

- It should auto-discover and auto-setup supported printers (using the 
correct PPD), so that the user usually does not need to do more than 
install the Printer Application and connect and turn on his printer.

- The Snap should contain a collection of an arbitrary number of PPD 
files, either the files themselves or a highly compressed 
self-extracting pyppd archive (https://github.com/OpenPrinting/pyppd).

- The web interface of the Snap should also allow manually adding print 
queues, for example with Generic PostScript PPD, for allowing 
alternative default option settings, and also for the user supplying a 
PPD via web form upload. Also blocking selected printer against 
auto-setup would be great (for example if you want to use your 
PostScript + PDF printer in driverless PDF mode).

When seeing the PCL sample Printer Application

https://github.com/michaelrsweet/hp-printer-app/

and also after some discussion:

Printer Applications: Retro-fitting classic drivers
https://lists.linuxfoundation.org/pipermail/printing-architecture/2020/003823.html

PostScript printers without PPD files?
https://lists.linuxfoundation.org/pipermail/printing-architecture/2020/003826.html

Canceling jobs in Printer Applications
https://lists.linuxfoundation.org/pipermail/printing-architecture/2020/003831.html

Filter Functions - Getting years of development in cups-filters into 
Printer Applications
https://lists.linuxfoundation.org/pipermail/printing-architecture/2020/003842.html

I can now imagine how to manage the treating of a job, but what did not 
get clear to me is where the (auto) setup of the print queues will go 
in, where the discovered printer is checked against the PPD repository.

Michael, Jai, could you help me here?

In the PCL Printer Application there is a call

papplSystemSetPrintDrivers(system, (int)(sizeof(names) / 
sizeof(names[0])), names, desc, pcl_callback, "hp_printer_app");

in the pcl_setup() function, supplying the pcl_callback() function and 
the pcl_callback() has driver_attrs as an output parameter. Is this what 
the Printer Application will answer to get-printer-attributes requests 
from clients? And pcl_setup() is supposed to populate it? Does this mean 
that I have to call the ppdLoadAttributes() function in the equivalent 
function in the PostScript Printer Application and assign its output to 
driver_attrs?

Or where do I have to call ppdLoadAttributes()?

Michael, Jai, could you help me here?

This would be the first retro-fit Printer Application for classic 
drivers. Further retro-fit Printer Applications for Foomatic, CUPS 
Raster drivers, ... will probably get much easier.

    Till

Re: [Printing-architecture] Printer Application for PostScript printers

[Till Kamppeter]

On 08/08/2020 10:32, Jai Luthra wrote:
> For the auto-setup, I am still working on it. But according to the 
> current plan(based on discussions with Michael and you), all that the 
> printer application will need to do is provide a callback that takes as 
> input the device id and returns the driver name(or "NULL" in case your 
> application doesn't support it).
> 
> Please note that this is not yet a part of PAPPL
> 
> https://github.com/michaelrsweet/pappl/pull/36
>

Great, thanks. So this callback function is probably expected to be 
written by the individual Printer Application developers?

    Till

Re: [Printing-architecture] Printer Application for PostScript printers

[Michael Sweet]

Till,

> On Aug 8, 2020, at 7:31 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 08/08/2020 10:32, Jai Luthra wrote:
>> For the auto-setup, I am still working on it. But according to the current plan(based on discussions with Michael and you), all that the printer application will need to do is provide a callback that takes as input the device id and returns the driver name(or "NULL" in case your application doesn't support it).
>> Please note that this is not yet a part of PAPPL
>> https://github.com/michaelrsweet/pappl/pull/36
>> 
> 
> Great, thanks. So this callback function is probably expected to be written by the individual Printer Application developers?

Yes, absolutely.  A printer application will use the device ID string to determine whether it can support a device.

________________________
Michael Sweet

Re: [Printing-architecture] Printer Application for PostScript printers

[Till Kamppeter]

On 09/08/2020 06:49, Michael Sweet wrote:
>> Great, thanks. So this callback function is probably expected to be written by the individual Printer Application developers?
> 
> Yes, absolutely.  A printer application will use the device ID string to determine whether it can support a device.

OK, thanks.

    Till