Hastings, Tom N wrote:
> ...
> 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.
???
My suggestion:
e. media-margin-sizes will contain 4 values if the margins
for the front and back side are the same or if simplex
printing is selected. If the margins are different
and duplex printing is selected, then 2 sets of 4
values (8 values total) will be returned.
> 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.
I disagree, since this would require server-side constraints to
be implemented. I think we should make constraints optional on
the server and mandatory on the client if the server supplies the
(new) constraints collection attribute.
Any server-side constraint checking should stay in Validate-Job,
Print-Job, and Create-Job (where IPP already defines some limited
stuff with the unsupported attribute group...)
> 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.
OK, I think there is a major dose of confusion here.
I didn't say anything about using the query operation for
constraints, I was speaking of getting the correct media-margin-sizes
values (and whatever other dynamic values) based on the provided
job template attributes.
papiPrinterQuery() should not do any constraint checking, it should
only be used to get 1) the supported attributes and values, 2) the
constraints between those attributes, and 3) any dependent printer
information such as margins.
Currently the IPP Get-Printer-Attributes operation can provide
additional information (supported N-up values, etc.) based on
the document-format attribute. If we extend this to all job
template attributes, then we're really putting a huge load on
the server...
Another option is to use the Validate-Job operation to get the
media-margin-sizes information, as well as doing the final
sanity check on the attributes...
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Fri Sep 27 2002 - 17:43:45 EDT