OpenPrinting / libcups

OpenPrinting CUPS Library Sources
https://openprinting.github.io/cups/cups3.html
Apache License 2.0
35 stars 17 forks source link

ipptool: Extend "DEFINE-VALUE" to accept a second "value" argument #6

Closed michaelrsweet closed 2 years ago

michaelrsweet commented 2 years ago

From @wifiprintguy in [ippsample issue 227]():

The current definition of the "DEFINE-VALUE" EXPECT PREDICATE is this:

DEFINE-VALUE variable-name
    Defines the variable to the value of the attribute when the EXPECT
    condition  matches.  A  side-effect of this predicate is that this
    EXPECT will never fail a test.

It would be very helpful in some contexts if the value could be set to something other than the value of the attribute matched by the EXPECT condition. If it had a second optional argument "[value]", the existing syntax would still work, but a specific value could be assigned that isn't the one from the attribute matched. The description would become this:

DEFINE-VALUE variable-name [value]
    Defines the variable to the value provided, or to the value of the
    attribute (first value from a 1setOf) when the EXPECT condition
    matches if a value is not provided. A side-effect of this predicate 
    is that this EXPECT will never fail a test.

An example of a scenario where this would be useful is found in the current ipp-tests.test test file used in the istopwg/ippeveselfcert. There are several lines that decide what resolution to use for PWG Raster documents. The raster files have names like "color-4x6-sgray-8-${RASTER_RESOLUTION}.pwg" where the "sgray-8" is unfortunately NOT the same as the keywords reported by the Printer's "pwg-raster-document-type-supported" (e.g. black_1, sgray_8, srgb_8) or else the existing DEFINE-VALUE predicate for EXPECT could be used.

With this change, we could leave the existing PWG Raster files in place but reduce the redundant sections of "ipp-tests.test" by replacing this:

EXPECT pwg-raster-document-type-supported WITH-VALUE "black_1" DEFINE-MATCH HAVE_BLACK
EXPECT pwg-raster-document-type-supported WITH-VALUE "sgray_8" DEFINE-MATCH HAVE_SGRAY
EXPECT pwg-raster-document-type-supported WITH-VALUE "srgb_8" DEFINE-MATCH HAVE_SRGB

with this:

EXPECT pwg-raster-document-type-supported WITH-VALUE "srgb_8" DEFINE-VALUE PWG_RASTER_TYPE "srgb-8"
EXPECT pwg-raster-document-type-supported WITH-VALUE "sgray_8" DEFINE-MATCH PWG_RASTER_TYPE "sgray-8"
EXPECT pwg-raster-document-type-supported WITH-VALUE "black_1" DEFINE-MATCH PWG_RASTER_TYPE "black-1"

so that later we could have one copy of tests like I-12 that could have a FILE directive like this:

FILE "pwg-raster-samples-$RASTER_RESOLUTION/black-1/onepage-letter-$PWG_RASTER_TYPE-$RASTER_RESOLUTION.pwg"

I'm sure it would be useful in other ways too.

michaelrsweet commented 2 years ago

The problem with this proposal is that DEFINE-VALUE would have ambiguous syntax. Perhaps add separate DEFINE and DEFINE-DEFAULT predicates to match the syntax of the existing top-level DEFINExxx directives?

michaelrsweet commented 2 years ago

From @wifiprintguy:

I'm fine with your proposal to add DEFINE as an EXPECT predicate. Not sure if we really need a DEFINE-DEFAULT as an EXPECT predicate too but if you think we do then let's go with it!

michaelrsweet commented 2 years ago

@wifiprintguy Given that we no longer use sample PWG raster files (but generate them on the fly), do you think we need this addition?

wifiprintguy commented 2 years ago

I don't think we need it anymore - if the need arises we can always reopen it or file a new enhancement.

michaelrsweet commented 2 years ago

Sounds good. Closing.