Add ability to generate PWG/Apple Raster print data to ipptool

[michaelrsweet]

In order to support #78, we need to update the self-certification tools to generate raster data to support any size, resolution, or color space. The existing JPEG and PDF test files can be used for those formats, regardless of media capabilities.

[wifiprintguy]

This should also let us resolve Issue #40.

[michaelrsweet]

Proposed changes for ipptool:

GENERATE-FILE {
    COLORSPACE "colorspace_bits, auto, color, monochrome, bi-level"
    FORMAT "image/pwg-raster, image/urf"
    MEDIA "media, ..., ready"
    NUM-COPIES "copies"
    NUM-PAGES "pages"
    ORIENTATION "portrait, landscape, reverse-landscape, reverse-portrait"
    RESOLUTION "resolution, min, max, mid"
    SIDES "sides"
}

Does a Get-Printer-Attributes request to get capabilities and match as needed.

Generated pages have a black border with the text "TEST-PAGE ####" repeated in different shades of gray/color.

For two-sided output, the back side images are transformed as needed.

The media list is matches against the printer capabilities (media-ready, then media-supported), with "ready" matching the current ready media.

Default values for all but NUM-PAGES can come from the job ticket (request) or from the xxx-default attributes.

[wifiprintguy]

@michaelrsweet can you provide it within the larger context of a complete single test or tests? I'm having a hard time understanding how it might be used.

[michaelrsweet]

@wifiprintguy Here is an updated snippet from the ipp-tests.test file:

# Test Print-Job operation
#
# Required by: RFC 8011 section 4.2.1
{
	NAME "I-12. Print-Job Operation (Print-Job Test)"
	OPERATION Print-Job
	GROUP operation-attributes-tag
	ATTR charset attributes-charset utf-8
	ATTR naturalLanguage attributes-natural-language en
	ATTR uri printer-uri $uri
	ATTR name requesting-user-name $user
	ATTR name job-name "Print-Job Test"
	ATTR boolean ipp-attribute-fidelity false
	ATTR name document-name "Print-Job Document"
	ATTR keyword compression none
	ATTR mimeMediaType document-format "image/pwg-raster"

	GROUP job-attributes-tag
	ATTR keyword media "$DEFAULT_MEDIA"
	ATTR keyword print-color-mode "$DEFAULT_PRINT_COLOR_MODE"
	ATTR enum print-quality $DEFAULT_PRINT_QUALITY
	ATTR resolution printer-resolution $DEFAULT_PRINTER_RESOLUTION
	ATTR keyword sides "one-sided"

	GENERATE-FILE {
            # Media, format, colorspace, resolution, sides, and copies inherited from request attributes
            NUM-PAGES 1
        }

	STATUS successful-ok
	STATUS server-error-job-canceled
	STATUS server-error-busy REPEAT-MATCH REPEAT-LIMIT 30

	EXPECT job-uri OF-TYPE uri COUNT 1 IN-GROUP job-attributes-tag WITH-VALUE "$IPP_URI_SCHEME"

	EXPECT job-id OF-TYPE integer COUNT 1 IN-GROUP job-attributes-tag WITH-VALUE >0
	EXPECT job-id DEFINE-VALUE PRINT_JOB_ID

	EXPECT job-state OF-TYPE unknown|enum COUNT 1 IN-GROUP job-attributes-tag WITH-VALUE 3,4,5,6,7,8,9
	EXPECT job-state WITH-VALUE 7,8,9 DEFINE-MATCH PRINT_JOB_COMPLETED

	EXPECT job-state-message OF-TYPE text IN-GROUP job-attributes-tag

	EXPECT job-state-reasons OF-TYPE keyword IN-GROUP job-attributes-tag
}

[wifiprintguy]

@michaelrsweet that makes sense. Would it be hard / awkward to use it when using Create-Job / Send-Document? How can we make sure that scenario (preferable to Print-Job from an IPP Implementor's Guide v2 perspective) is not unnecessarily painful?

[michaelrsweet]

@wifiprintguy It would work the same for Send-Document, although the inherited values wouldn't work from the preceding Create-Job request. I don't think this will be a problem for the kinds of tests we'll be using this for, but it will definitely be worth documenting.

[michaelrsweet]

OK, I have changes queued up in the "ipptool" branch of my libcups v3 project, and will back-port for ippeveselfcert once I am done with the changes. Longer term I think I'll just incorporate libcups as a Git submodule for this project and ippsample, but libcups v3 isn't fully baked yet... :)

[michaelrsweet]

[master 7b4f7ea] Add GENERATE-FILE support to ipptool (Issue #79)