In a rather adventurous attempt, i would like to try and do the following:
(Don't want to download all kinds of shareware tools. I would really like to do this with code)
1) Read all the pending print jobs in the Microsoft print queue. (For instance those jobs that lie there because the printer is off-line or broken.)
2) give an option for a new printer and move the pending jobs to a new printer.
Any ideas how I can start at point #1?
Using the Print Spooler API functions.
See: http://msdn.microsoft.com/en-us/library/windows/desktop/dd162751%28v=vs.85%29.aspx
Peter,
Not sure #2 is possible. If it is, then at the very least, I think the second printer would have to be the same model or a compatible model. That is because some program created that print file using a particular print driver. If the second printer is not compatible, then each program that printed a particular print job would have to re-print the job using another print driver.
Of course, I am basing that on my general knowledge of how printing in windows works. I could be wrong, but I don't believe I am.
Quote(Don't want to download all kinds of shareware tools. I would really like to do this with code)
I am curious if you found any tools that claim to be able to do this?
David
I'm not saying that I know how to do this, but it occurs to me that most apps must somehow pass the full path of the document file to the spooler/queue.
If you could retrieve the full path, then you could pass that to the next printer, and it will invoke its own drivers.
Then, you'd just clear the old print job and dump that printer-specific output file...
Please let me know if this idea is of any value... 'cause after doing the following research, I'm not sure if this will fly...
-John
Here's the page for Print Spooler API Structures:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd162864(v=vs.85).aspx
The JOB_INFO_2 data structure contains this member:
pDocument
A pointer to a null-terminated string that specifies the name of the print job (for example, "MS-WORD: Review.doc").
...but from this description it doesn't look like that's a full path.
ADDJOB_INFO_1
The ADDJOB_INFO_1 structure identifies a print job as well as the directory and file in which an application can store that job.
...but I can't tell if that's what we need...
DOC_INFO_1 structure, DOC_INFO_2 structure, and DOC_INFO_3 structure each have a member:
pDocName
Pointer to a null-terminated string that specifies the name of the document.
...and again, I can't tell from the description if that's the full path...
but perhaps more digging around these pages, it'll surface...
John,
Assuming that you could locate the original document, that might work on a very limited set of universally known file formats. Acrobat, MS Office Suite (Word, Excel, PowerPoint) etc. But most file formats out there are undocumented and/or proprietary.
And what if I selected the second paragraph and printed the selection? No document ever exists containing just the second paragraph. That points out that the document printed is a massaged version of the contents of the document it came from. For example, how similar is a printout from FF to the contents of the source files? Similar but, most assuredly, not the same. The user might have selected to print with a particular font and font size, or selected the option "Insert a page break between each Sub/Function". Both resulting in a printout different from the any document file.
I could print a web page, or a piece of it. My custom program can print calculations (and results of them) based on what the user selected and typed in without ever creating a document.
And now it seems that even the well known file formats mentioned in the first paragraph of my post are unlikely to result in a printout that is exactly like the user specified if "Automatically" printed again with the different print driver.
Not to mention the mess if, for instance, I printed a document and made additional changes then saved it. Discovered that the printer isn't working and ran my software to switch to another printer. I would presumably get something that contains the new version of the document. Something that I may or may not have wanted to happen.
I'm thinking that even if it is possible to recreate the queue contents automatically, it would be more practical to just printing it again manually.
Hi all
There are actually a nice little tool called Qcontrol which not only can move a pending print queue but also split it between several printers at once.
Like one job say utility bill companies, and print monthly accounts. So you set up a bunch of printers and this toll does the rest.
It is extremely small 2mb.
It got me thinking that its an interesting idea to look into.
http://www.andtechnologies.com/index.php?q=free-software/qcontrol (http://www.andtechnologies.com/index.php?q=free-software/qcontrol)
Peter,
That would be very useful in a business setting where the likelihood of there being more that one printer of a given model or compatible series. I downloaded it and installed it to check it out. Here is an excerpt from the help file:
QuoteThings to consider when moving jobs:
· Driver compatibility. Output from one printer driver for a specific printer is not guaranteed to be the same as on another, even if they use the same printer language such as PostScript or PCL.
· Language compatibility. Sending PostScript to a PCL printer will result in a printout of many pages of PostScript code (which is actually text).
This is not the complete list of considerations but these were the only relevant to our discussion.
I may have gotten off on a tangent here. Peter, you never have said if were wanting to move documents from one printer to another that uses the same print drivers, or from one printer to another that uses different drivers. I've been saying that only the second case is not likely to be possible.
I don't know, David,
I think my idea and the links I provided would meet Petrus' original option #2.
As I suggested, you would identify the source file, use the structures to identify which options had been selected, and then invoke submit that information to the new driver, and let it process and print.
I think that would handle all the points you raised. Well, most. You raised some pretty obscure conditions (like a document changed after invoking the print function) that were not mentioned in the original post, so I think those are not on the table.
In any case, Petrus' seems to have shifted his original objective from "doing it in code" and not downloading other's tools...
Well, I have my own fish to fry, and I hope Petrus has fun with his exploratory project...
Best regards,
-John
I need to understand how this print queue works in Windows.
Does windows "prepare" documents for a specific printer the second you click print and it goes to the queue, or does that happen the second it actually start to physically print the document?
If it does that, then one should be able to capture and "reprint" it, still using Windows' own printing capabilities.
In other words just withdraw the document in the queue, end re-enter it to another printer in a new queue.
That is what i think they are doing here. Because once "formatted" for output to a specific printer will be difficult to intercept and re-direct.
Hi Peter,
Refer to the links in my earlier message for lots of "how the print queue works". May not be exactly what you're looking for, but I'm pretty sure they'll put you in the right area.
It's been my understanding for many years that once you select the printer, the OS/spooler "prepares" the document for that particular printer. So you could not just move that "output file" to another printer of a different type.
That's why I suggested trying to locate the path to the source file, if it's stored anywhere... But I wasn't able to tell if it can be found; I know I couldn't find it via MSDN. (I'll try doing a search on my local machine for pending printfiles... If I find anything, I'll let you know.)
-John
Thanks John!
Sorry for the late response! I am studying in between and writing exams on Wednesday.
So life is hectic!
Thanks for the help! I appreciate it very much!
Well there has been a billions posts (even on the PB forum) on something like this on the web.
Appears, that it is indeed very tricky to move pending jobs. Intercepting them before they go to the queue can be done with a custom lister on a port like 9100. (I am clueless on this topic)
But there are a million solutions on the web that can split print jobs, but moving a pending one is rare.
Thanks for the advice. I know a lot more now that what i did before!
You're welcome - I can't tell you how many people have helped me, so it's nice to be able to "pass it along".
In my other message, I wrote Peter instead of Petrus; I apologize for misspelling your name.
Good luck with your studies! And, if I find out anything else about "print job source filename/path", I'll let you know.
-John
Hi John
;D
These Dutch names are HARD to pronounce anywhere else in the world.
So i asked most of the guys to call me PETER. So you were spot-on!
In English, Peter means the same as Petrus in Afrikaans. (A far-related language to Flemish and Dutch)
So for the sake of not twisting any tongues around here, feel free to go with PETER!
;D