IPP> MOD - 3/21 call [and request attributes by file-typ

IPP> MOD - 3/21 call [and request attributes by file-typ

Tom Hastings hastings at cp10.es.xerox.com
Fri Mar 21 18:36:39 EST 1997


Yes, to Roger's question (that removing file-type as an adornment and
adding an input parameter to Get Attributes that specifies the 
document-format job template being requested does) also simplifies a printer
that supports multiple document formats when all attributes and values
apply to all document formats.


Tom


At 07:03 03/21/97 PST, Roger K Debry wrote:
>Classification:
>Prologue:
>Epilogue: Roger K deBry
>Senior Techncial Staff Member
>Architecture and Technology
>IBM Printing Systems
>email: rdebry at us.ibm.com
>phone: 1-303-924-4080
>
>---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/21/97 07:59
>AM ---------------------------
>
>For those of us that were not on the telecon recently,
>Bob had a proposal to remove the file-type adornment and to
>allow the requester to specify a document-format as an input parameter
>to the Get Attributes operation on a Printer and the Printer would return
>only the attributes and values that apply to such a document-format.
>
>If the requester left out the document-format, the Printer would supply
>its default document format as the implicit input parameter to filter out
>attributes and values that don't apply.
>
>This sounded to me like a real simplification and what real users and
>client software needed, since the client software know what document
>format it is capable of producing and isn't interested in attributes
>and values that apply to other document formats.
>
>For a printer that only can consume a single document format, this new
>idea means that there is NO IMPLEMENTATION BURDER on the implementation
>for this
>
>RKD> Doesn't it also simplify the case where the attribute's might be the same
>for
>RKD> all document formats supported on that Printer?
>
>




Yes, it does.



More information about the Ipp mailing list