I think there are significant exceptions to your statement. In a Windows
environment, for example, the driver is not necessarily in charge of the whole
process. A "normal" driver may never know how many pages are in the job or is
likely to be able to find out only after the job had been fully built.
In Windows, the "originating application" (like Microsoft Word), may know the
number of pages, but doesn't do job monitoring. The port monitor in Windows
might know the number of pages, but only if either 1) it parses the data coming
through (whether it be PCL, PS, whatever), or 2) it finds it out from someone
else. The spooler will sometimes know the information (although I can tell you
from experience that what the spooler thinks and what the printer thinks are
*very* often two different things). And note that with a Windows 9x client
printing through a Windows NT print server, the job is sent from Windows 9x
already formatted and hence the spooler on Windows NT knows nothing about the
number of pages in the job, meaning the port monitor doesn't know either.
As far as an application that isn't "in-line" (that is, isn't part of the job
submission process), they in general will never know anything except from the
printer.
In the Unix world, a source told me that in general, in this specific area, the
effect of the architecture is similar to Windows: no one who might be
responsible for showing status knows how many pages there are.
Now, I agree that there are ways around the above problems, and I agree that
there are holes in my comments above. However, I believe that in a general
sense, it is non-trivial to set up a system as part of either the Windows or
Unix print subsystems, or as a stand-alone application, such that the monitoring
application *really* "knows" the total number of pages.
Dennis Carney
IBM Printing Systems (303)924-0565