Hi Bob:
Actually I am writing code for monitoring a printer with the help of Find*PrinterChangeNotification set of APIs, and follwing is my observation:
-In case of print job with RAW format, Total pages was received with correct
values, but Printed Pages was always recieved with the value 0. Total Bytes was
OK, but at the end of the print job, the Total Bytes and Printed Bytes were
different, the latter being lesser then former. So, it doesn’t help in
determining that whether a print job is finished or not.
And in one of the replies in this post you have mentioned that:
“these values will only be seen if someone (typically the
print processor) reports those values. In practice, this means they are only
valid when the print pass spools EMF, or a language monitor which can parse page
boundaries out of RAW data is used (the latter is a theoretical possibility, but
I don’t know if it’s been reduced to practice- Windows Printing System used such
a monitor, but I don’t believe it updated these fields).”
So it means that if the format is EMF some component typically the print processor (which converts from EMF to RAW) will be reporting these values, but in case of RAW (as is happening with my prototype), updation will not be done.
I tried to search for more detailed info on this in the DDk, and on the net…but couldn’t find any thing useful. Can you please suggest some info source, so that I can get enlightened.
Thanks
Pankaj
Hi Bob Kjelgaard:
I have written this reply with respect to one of the posts, I found in this forum, but my reply deosn’t show the rest of the post. I hope this will not cause inconvenience to you.
Thanks
Pankaj
Pankaj-
I’m afraid I can’t be of much help in this case. I learned Win32 printing “on the job”- I was the initial sole test developer for the print subsystem at the time it was first designed and implemented, and continued to work in this space in various projects for the next 10 years or so after that. The DDK documentation (IMO) has always been sketchy, and printing is usually in the bottom half of that space as far as what should be presented vs what actually is [again, IMO]. I already had a pretty good idea how it worked, and I found the documentation virtually unusable, so I can guess what it’s like for most developers.
I’ve never seen a decent book or forum on the subject myself, but then I rarely felt the need to really look (when I started, HTTP was in its infancy, after all). Perhaps you can get some pointers from some of those here with more recent experience. I know some of the current print team members occasionally post here [and there are several of the regulars who also know quite a bit and are more current].
With respect to the job fields, basically they get updated and generated based on traffic that comes through the spooler API. So if someone (for an off-the-wall example) prints NNNN bytes into the spool file, but then sends MMMM bytes to the port at despool time, those will be two different numbers at the end of the job. Page counts get updated explicitly via the Job API (IIRC- although if you use the EMF support calls, they probably do it on your behalf)).
Sometimes observation, head scratching analysis, and the occasional hopeful question is all you can do. In the end, that and a whole bunch of legwork is how I wound up getting any of it.
Best of luck
Bob Kjelgaard
Thank you Bob, for your reply and all the useful info in it.
Well, it will be great if other members in the forum, can also shed some light on this issue.
Precisely stated issue is:
When the print job is in RAW format, the Find*PrinterChangeNotification set of APIs, don’t provide correct values with the Printed pages notification (it’s always zero). It will be really great if some one can provide more information/web links etc on this scenario. Actually I want to understand it well and it will be helpful for me in my current project where I have to monitor printers using APIs.
Thanks
Pankaj
While there isn’t much published on it, the issue is pretty basic. As I remember it, to update the printed pages field, you use the SetJob Win32 API- the components capable of doing this get enough info (printer handle or name and Job ID) to find a way to do this.
The EMF print processor can do this for you, because EMF spool files are by nature page-based. It can even get it correct when doing N-Ups (don’t know if it does, though- I’m pretty sure the ones I wrote in the days when I did such things did), because it has to paginate the final output itself in these cases.
But the default RAW print processor (the code is in the DDK/WDK) just takes the stream of bits spooled by the printer driver and sends them directly to the monitor chain. It can’t tell where a page begins or ends [those bits can be anything- PCL /POSTSCRIPT /HPGL/ Esc-P /or literally dozens or hundreds of proprietary formats], so it is incapable of generating a correct count for you. Thus the printed page count is always 0.
You could only get such a count if a component that did understand each printer’s language was connected to the stream for each printer and was parsing those bits and then counting the pages for you. Nobody has ever done this that I know of for the general case- I know of specific instances (e.g., WPS and some things I did myself back in the day) where a language monitor or other downstream component does this, but only for a specific printer. It could be done for a few key PDLs and probably support the bulk of the market- I just doubt the payback is there unless you’re thinking about some FOSS solution [let’s see- a can of my favorite beverage, or the ability to know how many pages printed before I actually go and count them myself- I know my answer, and it says you can’t finance the development].
A printer manufacturer can certainly get the capability if they want to pay for it. I’m sure most would rather pay for something else. (That is all IMO, of course).
Which is what I probably meant to say in the first place, way back when.
hey pankaj,
Bob is the greatest help you can get out there! beleive me, he literally
spoon fed me in one of my projects. I shall remain ever grateful to hjim for
this. Without him, it would have taken me as much time (or more) as it took
Bob to get things figured out!
regards,
amitr0
On 2/16/07, xxxxx@yahoo.co.in wrote:
>
> Thank you very much Bob.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0