On 3/11/19 10:52 PM, Chris Murphy wrote:
On Thu, Feb 28, 2019 at 2:56 PM Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
> * Printing must work on at least one printer available to Fedora QA.
> "Work" is defined as the output from the device matching a preview
> shown on the GNOME print preview display. (Note that non-ridiculous
> differences in color reproduction are not considered "non-working". In
> general, we'll apply the "last blocker at Go/No-Go" principle here
> when deciding whether a print glitch is truly blocking.)
>
> and this to Final for Fedora 30+:
> * Printing must work (as defined above) on at least one printer using
> each of the following drivers:
> - The built-in print-to-PDF driver
> - The generic IPP driver
> * For each blocking desktop, it must be possible to print:
> - A test page from the desktop environment's built-in "test page"
> feature, if such a feature exists.
> - A simple text document of at least 100 words (lorem ipsum) from
> the standard basic text editor accompanying that desktop.
>
> This does not mean that all printers need to function properly that
> use the IPP driver, just that at least one does (so we
> know that printing as a whole is unbroken). We won't specify any
> particular hardware makes or models that must work.
I think "generic IPP driver" needs to be more specifically stated.
There's IPP protocol versions 1.1, 2.0, 2.1 and 2.2. The "driverless"
specification is IPP Everywhere, which uses IPP protocol versions 2.0
or higher, along with additional requirements to support driverless
device discovery and printing of text and images. There isn't strictly
speaking a generic IPP driver, although PCL and PostScript are common.
IMHO Stephen
meant it as driverless 'driver' or IPP everywhere enabled
printer, since 'generic IPP driver' does not exist.
What supports IPP Everywhere out of the box?
Any computer running CUPS 1.5 or later
I beg to differ that it is not entirely
correct. Yes, there are some
features for driverless support in <2.1.0 (approximately), but since it
was not so widely used at that time, some features were still missing or
needed some more tweaks for make it right.
Mobile devices running Android 4.4 and later
Proposal for Fedora 30: If anyone is able to, with reasonable effort,
successfully run the agreed test cases to any printer supporting IPP
2.0 or higher, using whatever driver is required, then we don't block.
I would go with 'if printing works on IPP everywhere printer available
for Fedora QA' (hooray, we have one :) ) 'then do not block'. But it
seems as technicality...
IMHO blocking the release if 'whatever' IPP everywhere printer does not
work seems like a trap to me - you basically believe that every printer
vendor implemented their IPP server and used HTTP server (IPP is
transfered by HTTP protocol) into printers firmware correctly - which is
not true till now.
Proposal for Fedora 31: If anyone is able to, with reasonable
effort,
successfully run the agreed test cases to any IPP Everywhere printer,
then we don't block.
Something I need to dig into deeper is how to create a virtual IPP
Everywhere printer (a service); which would be useful for testing, in
particular automated testing such that the virtual printer itself says
"yes this is a valid print job".
ippsample project does that, you can
find it in that github link you
posted, together with sample of ippserver, which should become 'server
solution' for CUPS (the idea is to use CUPS only as client app, and any
infrastructure servers will run only IPP server, which will present
printers to other machines).
But also it might be possible to
bridge the virtual IPP Everywhere printer with a conventional
CUPS+gimp/foomatic driver based printer.
This idea is similar to which Mike Sweet presented on PWG meetup last
year - printer applications - combination of IPP server(not
CUPS)+specific printer driver provider. I created a report from that PWG
meetup, please see that.
I plan to add all these projects into Fedora to have fully IPP
everywhere solution (ippusbx, ipp-selfcert, ippsample), but not so much
time to do it yet...
If so, I'm thinking Fedora
IoT on a Raspberry Pi Zero W, using a static containerized approach,
that once working, should be a reliable indicator that any failures
coinciding with print pipeline changes in the client, are in fact
client bugs. But we'll see about that.
This might be useful:
IPP Everywhere mini-tutorial
https://github.com/apple/cups/wiki/IPP-(Everywhere)-Mini-Tutorial
Other references:
IPP Everywhere FAQ:
https://www.pwg.org/ipp/evefaq.html
IPP Everywhere self-certified printers list:
https://www.pwg.org/dynamo/eveprinters.php
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C