Michael,
I have three issues about the media-margin-sizes (1setOf integer) Printer
Description attribute. I disagree with the idea that papiPrinterQuery
defaults omitted job context attributes. I also think we can do better for
the case of the back side having a different imageable area than the front
side.
Background for the sm and ipp DL: We are agreeing to add a
media-margin-sizes (1setOf integer) Printer Description as a way for the
driver to find out about the imagable area for IPP, PAPI, and the PWG
Semantic model. In PAPI, the papiPrinterQuery function accepts job context
attributes which narrow down the values of the returned attribute values
supported for any cross-attribute constraints.
ISSUE 1: How handle imageable areas that are different for the front and
back side of a medium?
Should the "media-margin-sizes" (1setOf integer) attribute:
a. return two sets of 4 integers, if the back side has a different set of
margins from the front side
b. always return 8 integers for each different medium when "sides" is or
could be 'two-sided-long' or 'two-sided-short'.
c. always return 8 integers.
d. only return the margins for the front side and don't worry about the back
side, even if different.
I suggest yes.
ISSUE 2: If "xxx" job context is supplied, what is returned for
"xxx-supported"?
Are all the values still returned, or only the supplied value for that
attribute?
If the idea is that the supplied attributes to papiPrinterQuery are
providing constraints, then the supplied value is a constraint in itself and
so other values are not supported. I think it is more consistent to return
only what is supplied and return all values for other attributes, except
values that are constrained.
So if the caller supplies "sides" = 'one-sided' and also requests
"sides-supported", then the papiPrinterQuery returns "sides-supported" =
'one-sided', even if the Printer supports several values.
ISSUE 3: Does papiPrinterQuery default omitted job context attributes or
not?
Does papiPrinterQuery:
a. default omitted job context attributes and so apply any inter-attribute
constraints that such defaults would imply OR
b. not default omitted job context attributes, but rather return all values
that are possible with any values of the unsupplied job context attributes,
i.e., returned the unconstrained values independent of the Printer's job
defaults.
Michael said that "sides" would be defaulted by the papiPrinterQuery, if the
caller didn't supply the "sides" attribute in the job context. Later,
Michael said that when the client omits all job context, that the
papiPrinterQuery will list all possible values. It would seem to me that
defaulting omitted job context attributes contradicts returning all possible
supported values when no context is supplied.
Lets take a simple example, using just "sides" and "media" job attributes.
Let's assume that a Printer supports "sides" = 'one-sided',
'two-sided-long', and 'two-sided-short' and "media" = 'na-letter-white', and
'na-letter-transparent'. Let's also assume that the policy is to consider
that printing two-sided on transparencies is an error, i.e., would violate a
cross-attribute constraint.
So here are the different results for different papiPrinterQuery calls:
Case supplied job context: papiPrinterQuery results:
---- --------------------- -------------------------
a. <empty> "sides-supported" = 'one-sided',
'two-sided-long',
'two-sided-short'
"media-supported" = 'a-white',
'a-transparent'
b. "sides" = 'one-sided' "sides=supported" = 'one-sided'
"media-supported" = 'a-white',
'a-transparent'
c. "sides" = 'two-sided-long' "sides-supported" = 'two-sided-long'
"media-supported" = 'a-white'
d. "media" = 'a-white' "sides-supported" = 'one-sided',
'two-sided-long',
'two-sided-short'
"media-supported" = 'a-white'
e. "media" = 'a-transparency' "sides-supported" = 'one-sided'
"media-supported" = 'a-transparency'
f. "sides" = 'two-sided-long' returns constraint violation error
"media" = 'a-transparency'
Note: in writing this example, it occurred to me that any supplied job
attribute should only return the supplied value in the "xxx-supported"
response, since the caller was constraining that attribute to that choice.
So I claim that any omitted job context attributes are NOT defaulted.
Otherwise, there isn't any way to get back all the unconstrained supported
values and the GUI couldn't put up all the unconstrained choices to the user
before the user makes any choices.
For example if the Printer did apply defaults, and the "sides" default was
'two-sided-long', there wouldn't be any way to get back the 'a-transparency'
value.
Also, if you buy the idea that a supplied "xxx" attribute only returns that
value for the "xxx-supported" value, then defaulting only returns the
supplied values, rendering papiPrinterQuery useless.
IPP Note:
RFC 2911 Get-Printer-Attributes does have the idea of defaulting for the
only job context attribute that the client MAY supply, namely,
"document-format" (which with hind-sight, I think was unfortunate):
If the client omits this "document-format" operation attribute, the Printer
object MUST respond as if the attribute had been supplied with the value of
the Printer object's "document-format-default" attribute. It is RECOMMENDED
that the client always supply a value for "document-format", since the
Printer object's "document-format-default" may be
'application/octet-stream', in which case the returned attributes and values
are for the union of the document formats that the Printer can automatically
sense.
Comments?
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Friday, September 27, 2002 05:42
To: printing-cap at freestandards.org
Cc: sm at pwg.org; ipp at pwg.org
Subject: Re: [printing-cap] Capabilities API: Device Object [How about a
M edia Object]
Hastings, Tom N wrote:
> ...
> The only problem left is what to return when the job context supplied
> doesn't specify enough to return a single set of margins? For
> example, if the margins depend on the media size, but the job context
> didn't have a media size. Or as another example, suppose the margins
But the printer object has defaults for all printing attributes,
which are used when the job object doesn't override them...
> depend on whether one-sided or two-sided printing is to be done, but
> the job context doesn't supply the "sides" attribute. How about just
Again, "sides" is defaulted.
However, in the case of many of the current HP inkjets with the
auto-duplexer option, the top and bottom margins are swapped for
the back page. In CUPS we have a PPD attribute for this, but in
general I'd suspect the sane thing to do would be to report the
same top and bottom margin (the larger of the two for safety, and
the app/user can still try printing outside of those margins)
> Comment on papiPrinterQuery: I assume that when the caller omits most
> or all of the job context, that what is returned is more like all
> possible things supported, rather than assuming the defaults for each
> of the job context attributes. That should be clarified (along with
> the union versus intersection issue).
If we use constraints, then the query operation without job attrs
will list all possible values (+ the constraints); the addition of
job attrs will only narrow the query results.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com
_______________________________________________
printing-cap mailing list
printing-cap at freestandards.orghttp://freestandards.org/mailman/listinfo/printing-cap