In addition to supporting the idea of adding a Media object,
which we should add as a future to PAPI, IPP, and the PWG Semantic model,
Michael wrote:
" > ...
> How about adding a member attribute to the "media-col":
>
> "media-margin-sizes" (1setOf integer)
I'm not sure adding it to the media-col attribute is the right
solution, for the reasons I specified earlier (other attributes
affect margins, too). It would probably be better to make it
an attribute of its own, independent of the media-col/media/
resolution/quality/etc. attributes."
Good suggestion. So don't add margin sizes to the "media-col" Job Template
attribute.
So we'd add a media-margin-sizes (1setOf integer) Printer Description
attribute that contains the 4 margin sizes.
When the client supplies the job context in the papiPrinterQuery (or
extended IPP Get-Printer-Attributes operation), the values returned reflect
what is possible given the supplied job attributes.
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 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 returning sets of 4 integers?
Each set of 4 represents a possible set or margins depending on what is
supplied with the job? So for example if the margin size is different for
na-letter versus iso-a4, there would be 8 integers returned.
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).
Tom