Opps, sorry, I guess a little context would help here...
On Mar 21, 12:24pm, JK Martin wrote:
You might view it as "an implementation choice"...but what about the
Specifically, if the system administrator changes the job defaults
between the time the job is submitted and the time the job starts being
processed for printing (ie, when you would do dynamic binding), then
the job may very well not be processed the way the user expected.
Recall that the user can list the target printer's default attributes
prior to submission, and then submit the job, believing that the
defaults are acceptable.
How would you guard against (ie, protect the user from) this situation?
On Mar 21, 11:07am, Gail Songer wrote:
> Subject: Re: IPP> MOD - I've posted some issues: isstnh03.doc .pdf-Re
>> We really need to be very careful about how this is defined. The definition
> that you have proposed is directly opposite the definition the provided by
> PJL. PJL defines 4 levels of a variable, the factory default(rom), the system
> default(nvram, ram), the PJL current(ram) and the modified print
>> "PJL resets conditions are more powerful. They load the User Default values
> into the PJL Current Environment, which are then loaded into the Modified
>> "In this document, the term PJL rest condition refers to any of the following
>> "* Power on
> "* UEL command
> "* @PJL INITIALIZE command
> "* @PJL RESET command
> "* @PJL JOB or EOJ command
> "* Other perint-specifi events
> " - Contol Panel Reset
> " - Implicit printer language switch
> " - Language specific exit command
> " - Data stream idle timeout"
> this is taken from HP's Printer Job Language Technical Reference Manual,
> copyright 1992 page 6-8.
>-- End of excerpt from Gail Songer