Hi, 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 <li...@colorremedies.com> wrote: >> On Mon, Feb 11, 2019 at 9:58 AM Stephen Gallagher <sgall...@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 >>> 30+: >>> * 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 >> latter: >> >> ^minor differences in color reproduction are not considered "non-working"; or >> ^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 printing. 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): >> https://github.com/freedesktop/libreoffice-test-files 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 > specific. > > >> >> >>> 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. Best regards, Zdenek CUPS Fedora maintainer > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
