I really like this proposal. Granted, it extends our reach yet
another step (in that we're not "going interactive"), but this
mechanism can be very, very useful in large environments, and may
be usable in billing situations, etc.
Regarding the language issue, couldn't we just add (yet another)
property to specify the language? This property would be set and
returned by the client at job submission time. I was thinking that
this would involve a list-selection mechanism, where the list entries
are the set of valid languages for which the Printer can handle.
Just my $0.02 worth. Nice job on the write-up.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Roger K Debry wrote:
>
> At the last PWG meeting, I suggested the definition of a new attribute,
> based on the proposed dictionary attribute, to allow an admisnistrator
> to collect end-user suuplied information to be printed on a job-sheet.
> I was asked to generate a formal write-up. Here it is:
>
> Job-Sheet-Content attribute
>
> Problem Statement
>
> Today the model document allows the end user to select whether or not a
> job sheet should be printed, but there is no mechanism for a user to
> specify what should be printed on the job sheet. In many cases, an
> administrator will establish the content of the job sheet, using
> information that comes from the print job request itself, such as
> job-name, or job-originating-user. However, these values are somewhat
> limited, and an administrator may want to use other information not
> available as a standard job attribute.
>
> Suggested Solution
>
> Using the proposed dictionary attribute (Hastings-deBry proposal),
> provide a means for the administrator to collect additional job-sheet
> information. This could incidentally be used for other purposes, such
> as accounting. This would be done with a new job template attributes
> called "Job-Sheet-Content".
>
> To help the client, each field to be printed on the job sheet is
> represented by a pair of attributes:
>
> 1. The first attribute in the pair is of the form "prompt-n",
> where n is a digit starting with 1.
>
> 2. The second attribute is of the form "prompt-n-response".
>
> This attribute provides a means for an administrator to collect
> additional user information to be printed on a job sheet. There
> is no standard set of semantics associated with the text data
> supplied by the administrator or the end user. Text is assumed to
> be in the language of the end-user.
>
> ISSUE: How does one associate the end-user's language with a set
> of text dictionary attributes? In a multi-lingual configuration,
> it must be possible for the server to select the dictionary entries
> based on the end user's language.
>
> For example, an administrator defines the job-sheet-content attribute
> as the following text attributes:
>
> "Prompt-1" = 'Last Name'
> "Prompt-1-response" = ' '
> "Prompt-2" = 'Department'
> "Prompt-2-response" = ' '
> "Prompt-3" = 'Building'
> "Prompt-3-response" = ' '
>
> In this example, the default values for the prompt-n-response attributes
> were set to a strings of ASCII blanks. They could have been any text
> string, perhaps a default name, or a string saying "enter text here".
>
> A client application, getting the job-sheet-content-supported attribute,
> would receive the above dictionary. Since there is no semantic associated
> with the actual text data, the client simply puts up the prompt and
> collects the response from the end-user in the associated response field.
> These fields are passed back to the IPP Printer with the print request
> where the data input by the end user is printed on the job-sheet in a
> format defined by the administrator.
>
> Roger K deBry
> Senior Technical Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry@us.ibm.com
> phone: 1-303-924-4080