comments are in the text:
On 2/11/19 9:17 PM, Stephen Gallagher wrote:
On Mon, Feb 11, 2019 at 2:24 PM Chris Murphy
> On Mon, Feb 11, 2019 at 9:58 AM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>> Sorry that it's taken me so long to get back to this.
>> I think the feedback on this has been mostly positive on the Beta
>> criteria, but I'd like to tweak the phrasing a bit and see if this
>> comes off more favorable:
>> I'd like to propose that we add the following criteria to Beta for Fedora
>> * 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 differences in
>> color reproduction are not considered "non-working".)
> Does the criterion pply strictly to the printing of text and line
> art, or does it also apply to gross departures in photographs? If the
> ^minor differences in color reproduction are not considered "non-working";
> ^only major differences in color reproduction are considered "non-working"
> Major defined as any of:
> obvious and grossly incorrect scaling (e.g. +/- 20%)
> color inversion, torqued primaries (white becomes black, black becomes
> white; red becomes blue, blue becomes green, etc)
> tone reproduction that obliterates relevant identifying detail in two
> or more test images
> With that language I'm trying to carve out only remarkable, WTF level,
> bugs as blockers.
I think we can *probably* leave this as a thing to be decided at a
blocker bug review. I really want to avoid trying to set a hard line
on a topic that is inherently subjective. In general, I think we can
just rely on the "last blocker at Go/No-Go" test for this.
I agree with
Stephen - such topics can be really subjective and even the
fault does not have to be on Fedora side (f.e. when you catch the file
which goes to the printer, you look into it and it looks fine, but
output paper has 'slightly' different colors, scale etc... - so there
can be issues in the printer itself).
> Next question is what applications to use for printing, since the
> initiating application matters. What if there's a bug in just one
> application? That shouldn't be a printing blocker (it might be a basic
> functionality blocker for that application if it's included in default
> installations). So I'd say pick two. Firefox and LibreOffice? Firefox
> and evince?
How about "Desktop environment's 'test page' functionality" and
whichever basic text editor comes with it.
IMHO it is not correct blocker criteria for printing as itself, but it
is more like blocker for these applications. AFAIK blocker is the issue,
which can not be worked around - if the file is printable by CUPS CLI
commands 'lp'/'lpr', but not from a app, IMHO it is not blocker for
IMO issues like 'not being able to print from X application' should be
blocking/release criteria for some common/widely used apps like
Firefox/evince/libreoffice, not for printing itself. (If the issue would
be actually connected to CUPS, I'll cooperate with them to fix the issue).
> Next question, test document(s). European Color Initiative has several
> test PDFs already prepared, perhaps the most applicable for our
> purposes is the visual test (and a subset of it).And for font scaling
> and reproduction, Ghent Working Group has test GWG 9.1 which tests
> various encodings of TrueType, PostScript, and OpenType rendering.
> Also, there's a suite of LibreOffice test files, and while I haven't
> gone through it, I'm willing to bet there's one or two that'd serve as
> a decent sanity tester (in any case I'm not proposing printing out
> entire test suites):
Chris, would you mind elaborating more on the topic of these test files
and tests from these sources? Martin (mosvald in CC) currently does only
comparing sample file and output file in ghostscript and I'm on my way
to do it the similar way in CUPS and printer driver packages.
Do they have special tests available to look into them? I saw mostly
only pdf file in ECI downloads, I did not see anything in GWG and only
docx or xlsx files in libreoffice tests.
> The nice thing about standardized tests is the far lower risk of bugs
> in the test file itself, and for sure the applicable developers are
> familiar with them so as they get escalated, it eliminates the kick
> back "how did you create this test file? can you attach it to the
> bug?" etc.
This sounds useful for automating the tests, but I think in general we
don't need to write this into the criteria. They don't need to be that
>> and this to Final for Fedora 30+:
>> * Printing must work on at least one printer using each of the
>> following drivers:
>> - The built-in print-to-PDF driver
>> - The generic IPP driver
>> To clarify, 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). Contrary to the first
>> proposal, we won't specify any particular hardware makes or models
>> that must work.
> I agree with this. One possible sanity test:
> 1. "Print" the standardized test file to a PDF file (using the
> built-in print to PDF driver)
> 2. Print both the resulting PDF from 1, and the original standardized
> test file, to the designated IPP printer.
> i.e. two physical prints on paper. And within some ballpark on
> scaling, they should appear the same. Some of the subcriteria:
> a. PDF file is created from test document
> b. PDF file is viewable with the default PDF viewer
> c. PDF file is printed
> d. Test document is printed
> e. minor differences aside: b, c, and d should not cause a WTF
> reaction by a human
That seems reasonable, though I'd rather have Master Wordsmith Adam
Williamson phrase that better.
I agree, although I would add printing to generic postscript printer,
because lots of devices are older and take postscript as input file type.
And IMO we can spare the paper in the most test runs, if we use
FileDevice print queue device type in testing - it is special type of
CUPS backend, which creates a file which should go to the printer in the
place specified in URI. The file is final output of all filters needed
for input file conversion (used filters differs according to input file
document format and printer's model) and ipp backend (which used for
sending filters output to printer), so it matches our needs imo.
But I will welcome suggestion for more sophisticated testing way than
comparison or checking file type.
CUPS Fedora maintainer
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Associate Software Engineer
Red Hat Czech - Brno TPB-C