I think one of the things that might be encouraging Mark to recommend a
"joined syntax" is the rate at which we keep inventing and/or applying new
access protocols to this information (SNMP, IPP, uPnP etc.). If we were to
define a joined syntax that concatenates the necessary information to
"use" the media in the device (including Media Size, Media Type, Media
Source, Media Name) there would be a greater chance of adoption across
protocols (new and revised).
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Hastings, Tom N" <hastings@cp10.es.xerox.com>
Sent by: owner-ipp@pwg.org
04/03/2001 01:30 PM
To: Mark VanderWiele <markv@us.ibm.com>, Norbert Schade
<norbertschade@oaktech.com>
cc: UPD group <upd@pwg.org>, IPP Group <ipp@pwg.org>, Pete Zannucci
<pzaan@us.ibm.com>, Mark_Hamzy/Austin/IBM%IBMUS <hamzy@us.ibm.com>
Subject: RE: UPD> Re: IPP> min/max custom size values
Mark,
I agree that real applications need to know about combinations of media
attributes. However, each print protocol has different ways to deal with
that. So I think it is wiser for the Media standard to just list the
names
of the various characteristics and leave it to the various Print protocols
do deal with combinations.
Ok?
For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing
Extension, which does combine the media attributes into a collection, so
that combinations can be configured by the administrator. However, even
that spec does not have a way for the client to query the supported
combinations. Last summer and fall, the IPP WG considered a proposal for
a
Resource object that had a number of operations to create, delete, and
query
Resource objects of a defined type. Media was a suggested type. Then the
group agreed that IPP should really have distinct set of operations for
each
object type, so that we need to write a spec for the Media object that has
operations, like Create-Media, Delete-Media, Get-Media-Attributes,
Get-Media
(with a filter).
Are you interested in seeing such a spec and reviewing and/or contributing
to it?
An another example or a print protocol that deals with the combinations
problem, the UPnP EnhancedLayoutPrint template defines a GetMargins
operation in which the input parameters are MediaType and MediaSize and
the
output parameter is the four margins. If the client supplies a
combination
of MediaType and MediaSize that is not supported, the Printer MUST return
an
error code.
Thanks,
Tom
-----Original Message-----
From: Mark VanderWiele [mailto:markv@us.ibm.com]
Sent: Friday, March 30, 2001 07:44
To: Norbert Schade
Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS
Subject: Re: UPD> Re: IPP> min/max custom size values
Careful, we may be making the same mistake we made in IPP where the form
size, media type, and tray are returned separately causing user interface
nightmare since all three of these really must be selected together and
represent the actual configuration of the printer. Therefore, I would
propose that when we have settled in on a syntax for the form size, media
type, and tray we go one step further and define a way to join the fields
so that the proper constraints can be represented. Perhaps a simple "+"
character. Again, form size by itself is meaningless.
Regards,
Mark VanderWiele
IBM, Linux Tecnology Center
512-838-4779, t/l 678-4779
MARKV@IBMUS
email: markv@us.ibm.com
This archive was generated by hypermail 2b29 : Tue Apr 03 2001 - 16:40:36 EDT