We help IT Professionals succeed at work.

Do I have to cache data before sending to a printer

I have been tasked with a large amount of printer work.  When printing large amounts of data (possibly thousands of pages) I need to know concretely what my options are.

So far, my understanding is that all data, regardless of size, needs to be cached and then sent to the printer.  For example, in c#, I have written a custom paginator that is tailored to what my project needs to print.  I have to give that paginator a data source, which then goes and prepares each page until it has iterated through the entire data source.  This means I have to supply the whole data source up front (this is what I mean by caching).  I send the paginator to the printer which actually executes the paging code and does the iterations through the data source.  This approach creates a single print job in the printer's queue.  

Today I was told by superiors that competitor product(s) actually send each page to the printer as they come in from across the network.  They are saying that when a thousand pages are printed, the application receives the first page, sends it to the printer, receives the second page, sends it to the printer, and so on until the very last page.  They told me I need to do it this way.  I have some concerns with this approach.  Namely, that even if things did work this way they are actually creating 1,000 print jobs in the printer's queue/job tray.  If, in the middle of this giant list of jobs (each job being a single page) someone decides to print something else like say an email they received or an invitation to their daughter's birthday party, the email or invitation would be outputted in the middle of the 1,000-job pages (they'd be a mixed mess that someone would have to sort through once all the printing was done).

I would like to get a little insight on best practices involving my scenario and if I correctly understand how printer queues work.  Also, I would like to know if it is possible with c# to send one page at a time to the printer but still maintaining one single print job (regardless of how many pages there are overall) sort of like treating the printer as a stream and "streaming in" each page as it comes in while the one single print job in the print queue/tray remains open.

I want to say right off the bat that this whole thing is stupid and that they are wrong, but before I send off a fiery email I'd like to verify my understanding.

Thank you for your assistance and please let me know if I can be more clear.
Comment
Watch Question

Author

Commented:
(side note, I think it's pretty cool that I subbmitted the question at 11/1/11 at 11:11 am!  I didn't plan that at all)
>>  ... send each page to the printer as they come in from across the network ...

This would probably result in each page being treated as a separate job, which (as you surmise) could mean that pages from other jobs get interleaved; it could also possibly severely affect throughput.

I say 'probably', because if the data was coming in sufficiently quickly, presumably your 'paginator' could output multiple pages; this rather depends on just how this 'paginator' works.

If your code wrote to a 'spool' file, which is only released once the spool is complete, then you wouldn't have a problem - except that nothing would be sent to the printer until the spool was complete (which is presumably not what your managers want).

... and another thing to consider; how does your paginator know when the batch of pages "as they come in from across the network" is complete.
... and your post (in my timezone (GMT)) was recorded at 2011-11-01 18:11.
CERTIFIED EXPERT
Top Expert 2015
Commented:
I might be wrong, because I have not done a lot of printing except through report generators, but in my minimal experience, it is the printer driver that control most of that stuff.

There is an option for each printer (throught the Control Panel) to check if you spool documents or not. If you decide to spool, there is another option to decide if you want to spool the whole document before sending to the printer, or if you want to start the printing as soon as data is available.

This is under the user control. So, maybe when the people tell you that they have an application that sends things page by page, they are on a computer that is set to start spooling as soon as data is ready, so they see the printing start, and at the same time they see page number increment in the printer display.

From you application, if you use the standard PrintDocument class, it does automatically lets you send the data page by page, because its use forces you to react to the PrintPage event that is called for each page, as long as its e.HasMorePage parameter is True.

So, sending the pages one by one is the way the PrintDocument object works. The spooling (cache) is controlled by the user in the ControlPanel. You do not have to fear that other jobs will interwine with yours, they will be on hold until you tell the system that you are finished.

Author

Commented:
Thank you for your help.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.