HP PCL/PJL reference - Printer Job Language Technical Reference Manual
EN Programming Tips for Using PJL 11-27
Application Design Ideas
The previous pages have described various printing system
topologies and how components in those topologies can operate so
each printer system component can receive printer status readback
responses. This section discusses application design ideas that
handle the complexities involved with using printer status readback
information.
The obvious design approach of querying the printer and waiting for
an answer to that query is sure to lead to failure. A busy printer, old
printer responses, overflowed printer response buffer, and a
uni-directional printing environment all cause the obvious design
approach to be inadequate. A better design approach is to treat
printer responses as events that cause the application to take some
action. Solicited and unsolicited printer status readback
queries/responses are discussed separately.
Whenever the application sends a solicited query to the printer, the
application should add the query to the “outstanding solicited query”
list. Also, if the application can not proceed until the response is
received, then a watchdog timer should be set so that some event will
be guaranteed to occur in case the application does not receive a
timely response. Whenever a solicited response is received, the
response should be compared to the list of outstanding solicited
queries. If there is no match, then the solicited response should be
discarded. If there is a match, then the query should be removed from
the outstanding solicited query list, any associated watchdog timer
should be disabled, and the application should process the response.
If the application was blocked waiting for the response, then the
application should become unblocked.
If the application does not need an unsolicited status response, then
the application can discard the response.
If the application ever receives the unsolicited PJL “printer to host
data buffer overflow” message, then the application should resend all
queries in the “outstanding solicited query” list. When the application
resends the outstanding solicited queries, it is possible that the
application will receive two responses (one generated because of the
initial query and one generated because of the resent query). If the
application is using an outstanding solicited query list, then when the
first response is received, the query will be removed from the list.
When the second response is received, the second response will be
ignored because there is no matching query in the outstanding
solicited query list.