|
Henk,
The accounting may be off a few pages *PER JOB*. After many
jobs, the net [cumulative] effect can be significant.
It is understood that due to latency in the printer
the accounting information is not accurate. I also get to
know that this is mostly seen in duplex printers.
Currently there is known workaround to this problem.
-Harish Kamath.
|
| Harish,
Thanks for yoyr reply.
What can you say about the pagecount operator, is the pagecount returned
from the printer (also) incorrect?
What exactly do you mean with the latency in the printer? Is the
printer not able to count the pages correct? If yes, then I expect the
pagecount also to be incorrect.
Regards,
Henk.
|
| The 'pagecount' operator IS the method by which the number of pages printed
is reported through DCPS to implement accounting.
The "latency" referred to is because the PostScript interpreter maintains
the page count and responds to the pagecount operator, but the interpreter
depends on page printing and delivery completion by the engine, which does
not take place until the pages have been released by the interpreter
and passed through the engine. Harish's reference to duplex printing
is due to the twice-through-the-printer paper path that duplex printing
requires.
As far as I know, the page count does catch up, and if a job can wait
a half minute or so to inquire page counts, the actual returned count will be
accurate. But DCPS can't wait a half minute, so it asks for the count
right away and returns what the printer returns, which isn't quite up to date.
If the customer has more clarification about what "way off" might mean,
I'd like to hear it.
- tom]
|