Test I-20: Streaming Printer that flow controls document content blocks execution of I-20.1

[wifiprintguy]

Test I-20 has a PAUSE directive that pauses test execution, instructing the tester to remove the media from all input trays, and then hit space. Once the tester removes the media and hits space, the Print-Job operation will commence. But if the Printer inhibits the transmission of the document data because it is a streaming printer, the Print-Job operation in I-20 will block. That prevents the I-20.1 test from executing because the tests are serialized.

If the I-20.1 test is copied to a separate .test file and started in a separate shell before hitting the space bar to clear the PAUSE, the I-20.1 test completes successfully even though the I-20 test is still blocked. Putting paper into the Printer (and possibly pressing a button on the printer console) ought to cause the Printer to unblock data transmission, receive the whole document, and allow the Print-Job in I-20 (or Send-Document, if I-20 were rewritten) to complete.

So, somehow make it so that I-20 can block and not inhibit the execution of I-20.1, to better support IPP Streaming Printers.

[wifiprintguy]

If we move I-20.1 to a separate .test file, the "ipp-tests.sh" could fork that off into a separate shell before running I-20. Once I-20.1 completed, a PAUSE message or something could tell the user to put the media back in, which ought to unblock the transmission and let the Job complete.

[michaelrsweet]

@wifiprintguy ipptool does not offer any method of "forking off" tests or running tests in parallel. In theory this could be added but will require major changes to ipptool.

[wifiprintguy]

@michaelrsweet agreed - that would require a lot of changes in ipptool.

Before we spend too many cycles thinking about how to support this change, can you first confirm that the behavior exhibited by the Printer is the behavior the IPP WG would expect a streaming IPP printer to exhibit in an "out of media" condition?

[michaelrsweet]

@wifiprintguy Yes, a streaming printer would exhibit that behavior, which is why the original 1.0 tests used a JPEG file (where JPEG typically is held in memory and printed rather than streamed)

[wifiprintguy]

So in the short term, can we have I-20 / I-20.1 use JPEG if supported and fall back to PWG Raster if it isn't supported? And then once istopwg/ippsample issue #221 is implemented, we can depend on that as a better long term solution?

istopwg/ippsample#221

[michaelrsweet]

[master d3fcf71] Use MONITOR-PRINTER-STATE to support media-needed test with PWG raster (Issue #68)

[michaelrsweet]

@wifiprintguy Can you run some tests with the current Github sources to confirm this is fixed for you?

[wifiprintguy]

I don't think we are out of the woods yet...

With a Deskjet 3755 (already certified v1.0), I'm seeing a stall in I-20 after removing the media and hitting spacebar. The MONITOR-PRINTER-STATE directive doesn't seem to be causing ipptool to spawn a background thread and start monitoring the printer state. And the foreground thread seems to be TCP flow controlled. Perhaps the background thread needs to be spawned earlier?

I sent you a pcapng and terminal trace.

[michaelrsweet]

@wifiprintguy Try the latest code from master. I added a "DISPLAY-MATCH" directive to ipptool and now a message comes up to tell the operator to insert paper when needed. I also updated the "remove paper" instruction to match...

[michaelrsweet]

Fixed in 1.1 update 3.