Packaging Print Jobs
- E. Bartzokas
- Posts: 114
- Joined: Tue Feb 14, 2006 8:13 am
- Location: Corinth, Greece
Packaging Print Jobs
Hi all,
Once upon a time in MS-DOS we could do multiple print jobs to get inside one file in append mode with SET PRINTER TO myfile.txt ADDITIVE.
Today, with all the bells and whistles of windows, it seems that we cannot directly apply the above, and rather create all the nice graphics with different fonts and images, etc.
Our problem is this:
Our reports consist of several print jobs (e.g. COVER PAGE, SUMMARY, DETAILED REPORT, etc), each sent to the printer as one print job.
There is no real problem with single users, but it when it comes to printing to a network printer, it appears that everything is messed up somehow.
For example PC A, sends its COVER PAGE to the printer, and at the same time, PC B sends its own COVER PAGE (for another company).
Right after that, PC A send the SUMMARY PAGES (it can be between 1 page to several pages), and PC B sends its own SUMMARY PAGES....
On the printer paper tray, we end up most of the time, with mixed pages from PC A and PC B, and need someone to spend several minutes puting an order to the mess and separate each page.
I wonder if there is any way to "que" our print jobs without going to the printer, and send it when we're done with printing of all reports from one workstation, so the print job will be printed in whole, without printing other pages in between.
I hope that some other fellow programmers have ran/run into this problem, and perhaps someone has found a solution to it.
Like I said, it's the network printer that creates the above problem, and not printers connected locally to a non-network PC.
I would like to thank everyone who would like to shed some light to our problem.
Kind regards to all
Evans
Once upon a time in MS-DOS we could do multiple print jobs to get inside one file in append mode with SET PRINTER TO myfile.txt ADDITIVE.
Today, with all the bells and whistles of windows, it seems that we cannot directly apply the above, and rather create all the nice graphics with different fonts and images, etc.
Our problem is this:
Our reports consist of several print jobs (e.g. COVER PAGE, SUMMARY, DETAILED REPORT, etc), each sent to the printer as one print job.
There is no real problem with single users, but it when it comes to printing to a network printer, it appears that everything is messed up somehow.
For example PC A, sends its COVER PAGE to the printer, and at the same time, PC B sends its own COVER PAGE (for another company).
Right after that, PC A send the SUMMARY PAGES (it can be between 1 page to several pages), and PC B sends its own SUMMARY PAGES....
On the printer paper tray, we end up most of the time, with mixed pages from PC A and PC B, and need someone to spend several minutes puting an order to the mess and separate each page.
I wonder if there is any way to "que" our print jobs without going to the printer, and send it when we're done with printing of all reports from one workstation, so the print job will be printed in whole, without printing other pages in between.
I hope that some other fellow programmers have ran/run into this problem, and perhaps someone has found a solution to it.
Like I said, it's the network printer that creates the above problem, and not printers connected locally to a non-network PC.
I would like to thank everyone who would like to shed some light to our problem.
Kind regards to all
Evans
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Evans,
I think the key is that you can't call ENDPRINT before you are done with all the "reports." Ending the print device signals the Windows print spooler that the print job is done.
Below is an example using TPrinter that prints two "reports" in one print job. If you need to use TReport, you can try not calling ENDREPORT.
James
I think the key is that you can't call ENDPRINT before you are done with all the "reports." Ending the print device signals the Windows print spooler that the print job is done.
Below is an example using TPrinter that prints two "reports" in one print job. If you need to use TReport, you can try not calling ENDREPORT.
James
Code: Select all
// Purpose: Showing Multiple reports in one print job.
// Date : 5/10/2006 3:37PM
// Author : James Bott, jbott@compuserve.com
#include "FiveWin.ch"
//----------------------------------------------------------------------------//
function Main()
local oPrn, oFontm, nRow:= 20, nCol:= 40, i:=0
PRINT oPrn NAME "Testing the printer object" PREVIEW
DEFINE FONT oFont NAME "ARIAL" SIZE 0, -10 OF oPrn
oPrn:setFont(oFont)
// Print the cover page
PAGE
oPrn:say( nRow, nCol, "Cover Page")
ENDPAGE
// Print the detail pages
for i:= 1 to 3
PAGE
oPrn:say( nRow, nCol, "Detail Page: "+ alltrim(str(i)))
ENDPAGE
next
ENDPRINT
oFont:End()
return nil
- E. Bartzokas
- Posts: 114
- Joined: Tue Feb 14, 2006 8:13 am
- Location: Corinth, Greece
James,
Thanks for the reply.
Our problem seems to be more compilcated than this...
Here's what we have...
PRINT OPRN TO (CPRINTER) NAME "COVER_PAGE"
...
ENDPRINT
Calculations for Summary Report
PRINT OPRN TO (CPRINTER) NAME "SUMMARY_REPORT"
...
ENDPRINT
Calculations for Detailed Report
PRINT OPRN TO (CPRINTER) NAME "DETAILED_REPORT"
...
ENDPRINT
Calculations for Job Costing
REPORT OREPORT NAME "JOB_COSTING"
...
ENDREPORT
Calculations for Workers' Compensation Report
REPORT OREPORT NAME "W_C_REPORT"
...
ENDREPORT
Calculations for Month End...
PRINT OPRN TO (CPRINTER) NAME "MONTH_END_REPORT"
...
ENDPRINT
etc, etc.
Each print job above is spread into several functions in our PRG's.
It's not easy to start a print job (although your thought is correct, and we also thought about it already), due to some factors that might or might not end the print jobs above at the right point.
Especially the transition between PRINT OPRN and REPORT OREPORT is the worst part...
Anyway, a though could be to create a PDF with all print jobs combined into one document and when done, send it to Adobe for printing.
Thanks again for your reply.
Perhaps, if we have the time, to start digging among our PRG's and see if we can manage to create a complete job, including all subsequent jobs for one company (individual company reports).
I am obliged that you have responded.
Kind regards
Evans
For Paysoft, Inc.
Thanks for the reply.
Our problem seems to be more compilcated than this...
Here's what we have...
PRINT OPRN TO (CPRINTER) NAME "COVER_PAGE"
...
ENDPRINT
Calculations for Summary Report
PRINT OPRN TO (CPRINTER) NAME "SUMMARY_REPORT"
...
ENDPRINT
Calculations for Detailed Report
PRINT OPRN TO (CPRINTER) NAME "DETAILED_REPORT"
...
ENDPRINT
Calculations for Job Costing
REPORT OREPORT NAME "JOB_COSTING"
...
ENDREPORT
Calculations for Workers' Compensation Report
REPORT OREPORT NAME "W_C_REPORT"
...
ENDREPORT
Calculations for Month End...
PRINT OPRN TO (CPRINTER) NAME "MONTH_END_REPORT"
...
ENDPRINT
etc, etc.
Each print job above is spread into several functions in our PRG's.
It's not easy to start a print job (although your thought is correct, and we also thought about it already), due to some factors that might or might not end the print jobs above at the right point.
Especially the transition between PRINT OPRN and REPORT OREPORT is the worst part...
Anyway, a though could be to create a PDF with all print jobs combined into one document and when done, send it to Adobe for printing.
Thanks again for your reply.
Perhaps, if we have the time, to start digging among our PRG's and see if we can manage to create a complete job, including all subsequent jobs for one company (individual company reports).
I am obliged that you have responded.
Kind regards
Evans
For Paysoft, Inc.
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Evans,
The below example with both TPrinter and TReport reports also works, so I think it can be done. You may still have to modify TReport if you want to do multiple TReports in the same print job, since I think it forces and endprint.
You can also do all your calculations upfront before any of the reports. In fact, doing your calculations during the printing may be the problem. Network spoolers generally have a timeout when they consider the print job done. If you are printing then calculating, the calculation time may be longer than the timeout for the spooler, causing the end of a "print job." If you did all the calculations up front, then all the reports in quick succession, you may not have the problem you are now having. It might still be possible with heavy multiple users, however.
The best solution would still be a single print job.
In case you don't already know this, I have done work for Chris before (I am in San Diego). If you and/or he wants me to look into this, I will be glad to do so, but I will charge for my time.
Regards,
James
The below example with both TPrinter and TReport reports also works, so I think it can be done. You may still have to modify TReport if you want to do multiple TReports in the same print job, since I think it forces and endprint.
You can also do all your calculations upfront before any of the reports. In fact, doing your calculations during the printing may be the problem. Network spoolers generally have a timeout when they consider the print job done. If you are printing then calculating, the calculation time may be longer than the timeout for the spooler, causing the end of a "print job." If you did all the calculations up front, then all the reports in quick succession, you may not have the problem you are now having. It might still be possible with heavy multiple users, however.
The best solution would still be a single print job.
In case you don't already know this, I have done work for Chris before (I am in San Diego). If you and/or he wants me to look into this, I will be glad to do so, but I will charge for my time.
Regards,
James
Code: Select all
// Purpose: Showing Multiple reports in one print job.
// Date : 5/10/2006 3:37PM
// Author : James Bott, jbott@compuserve.com
#include "FiveWin.ch"
#include "report.ch"
//----------------------------------------------------------------------------//
function Main()
local oPrn, oFontm, nRow:= 20, nCol:= 40, i:=0
PRINT oPrn NAME "Testing the printer object" PREVIEW
DEFINE FONT oFont NAME "ARIAL" SIZE 0, -10 OF oPrn
oPrn:setFont(oFont)
PAGE
oPrn:say( nRow, nCol, "Cover Page")
ENDPAGE
for i:= 1 to 3
PAGE
oPrn:say( nRow, nCol, "Detail Page: "+ alltrim(str(i)))
ENDPAGE
next
use employee
report oReport title "Summary Report" to device oPrn
COLUMN TITLE "Name" DATA name
endreport
activate report oReport
use
//ENDPRINT
oFont:End()
return nil
- E. Bartzokas
- Posts: 114
- Joined: Tue Feb 14, 2006 8:13 am
- Location: Corinth, Greece
James,
Thanks for all the advises.
The calculations are indeed performed before starting eacg print job.
I understand that REPORT.PRG needs to be modified to suit our needs, and it's already been modified to do other things.
I know you have worked for Chris... I have spent time in El Cajon and work with Chris for the last 6 years, however, we never had the opportunity to meet each other at San Diego, due to my heavy schedule.
I lived at Chris' mother's house with my wife while there, and would probably stay in the US 'till now, however, my wife has a health problem since 2002, and she can't travel longer than 2-3 hours without relaxing, so we are stuck in Greece (my country). I work through net meeting with Chris (Pacific working hours), and for long periods of time, Chris stays here in Greece at the same city where I live, thus we also have a close cooperation. Also, Boris Pekic works with us from Belgrade.
To get back to the subject...
I am completely aware of the functionality of the printers (setup), and also, of the internals of the REPORT class and PRINT class.
The way our program is structured, it's really hard to allow for room to leave a PRINT job open, or a REPORT open... the reason is simple...
Many of our print jobs and reports, might be printed (if it's time to print them), or not printed, thus we need a big PRINT - ENDPRINT, and to be honest with you, sometimes it's hard to know where a print package ends.
Another thing is that the users have the ability to print single print jobs (and even preview them before sending to the printer)... That's another if-end situation here, as to closing the print job when printing as individual print job, or leave it open 'till the whole package has been completed.
The best approach, was to use PDF995's ability to create Combined.pdf (or with any name), which is controllable through our software (when to start spooling to one single file, and when to end).
Some of our clients, have found this option as handy, and have already started using it, so, when 2-3 PC's send their "Combined.pdf" to the very same network printer, it has resulted as a way to go.
Their print jobs come as a complete package, because they practically print one and only one file to the printer, and not multiple print jobs.
This way, the client's packages of reports are no longer mixed up, and it seems that it is the solution we need. There are minor details to fix now, and that is speeding up the process, by allowing the users to skip the pdf encryption which takes some seconds to be done. If we skip the encryption of this single pdf file, then the time needed to create the file Combined.pdf, is the same as sending the printouts directly to the printer.
The PDF995 is part of our application. We have built our application based on the PDF995 abilities. It's up to our clients to avoid having the splash screens (popups), by purchasing their licenses for 9.95$ each PC.
Not a big deal I guess, and it helps us create the "package" of reports, name it to any name we want when done, and attach it to emails.
Thanks again.
This is why I like Fivewin programming... There will always be someone to be on our side when we need help.
Greetings from Corinth Greece
Evans Bartzokas
Thanks for all the advises.
The calculations are indeed performed before starting eacg print job.
I understand that REPORT.PRG needs to be modified to suit our needs, and it's already been modified to do other things.
I know you have worked for Chris... I have spent time in El Cajon and work with Chris for the last 6 years, however, we never had the opportunity to meet each other at San Diego, due to my heavy schedule.
I lived at Chris' mother's house with my wife while there, and would probably stay in the US 'till now, however, my wife has a health problem since 2002, and she can't travel longer than 2-3 hours without relaxing, so we are stuck in Greece (my country). I work through net meeting with Chris (Pacific working hours), and for long periods of time, Chris stays here in Greece at the same city where I live, thus we also have a close cooperation. Also, Boris Pekic works with us from Belgrade.
To get back to the subject...
I am completely aware of the functionality of the printers (setup), and also, of the internals of the REPORT class and PRINT class.
The way our program is structured, it's really hard to allow for room to leave a PRINT job open, or a REPORT open... the reason is simple...
Many of our print jobs and reports, might be printed (if it's time to print them), or not printed, thus we need a big PRINT - ENDPRINT, and to be honest with you, sometimes it's hard to know where a print package ends.
Another thing is that the users have the ability to print single print jobs (and even preview them before sending to the printer)... That's another if-end situation here, as to closing the print job when printing as individual print job, or leave it open 'till the whole package has been completed.
The best approach, was to use PDF995's ability to create Combined.pdf (or with any name), which is controllable through our software (when to start spooling to one single file, and when to end).
Some of our clients, have found this option as handy, and have already started using it, so, when 2-3 PC's send their "Combined.pdf" to the very same network printer, it has resulted as a way to go.
Their print jobs come as a complete package, because they practically print one and only one file to the printer, and not multiple print jobs.
This way, the client's packages of reports are no longer mixed up, and it seems that it is the solution we need. There are minor details to fix now, and that is speeding up the process, by allowing the users to skip the pdf encryption which takes some seconds to be done. If we skip the encryption of this single pdf file, then the time needed to create the file Combined.pdf, is the same as sending the printouts directly to the printer.
The PDF995 is part of our application. We have built our application based on the PDF995 abilities. It's up to our clients to avoid having the splash screens (popups), by purchasing their licenses for 9.95$ each PC.
Not a big deal I guess, and it helps us create the "package" of reports, name it to any name we want when done, and attach it to emails.
Thanks again.
This is why I like Fivewin programming... There will always be someone to be on our side when we need help.
Greetings from Corinth Greece
Evans Bartzokas
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Can't you just remove any PRINT/ENDPRINT (even those inside the classes) and issue it manually at the very start and very end of your printing PRG?E. Bartzokas wrote:The way our program is structured, it's really hard to allow for room to leave a PRINT job open, or a REPORT open... the reason is simple...
Many of our print jobs and reports, might be printed (if it's time to print them), or not printed, thus we need a big PRINT - ENDPRINT, and to be honest with you, sometimes it's hard to know where a print package ends.
EMG
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Evans,
Glad to hear the PDFs are working for you. In your situation that does seem like the better solution.
The discussion has forced to me think about the issue, and I can now see a solution to some of the multiple report previewing problems I was having. I was just doing multiple previews (somewhat annoying), but now I can force them all into one preview. Thanks for that.
Sorry to hear about your wife's health issues. I hope she is improving. I guess it is a good excuse to travel by cruise ship--nice and relaxing.
Say "Hi," to Chris and Boris for me.
Regards,
James
Glad to hear the PDFs are working for you. In your situation that does seem like the better solution.
The discussion has forced to me think about the issue, and I can now see a solution to some of the multiple report previewing problems I was having. I was just doing multiple previews (somewhat annoying), but now I can force them all into one preview. Thanks for that.
Sorry to hear about your wife's health issues. I hope she is improving. I guess it is a good excuse to travel by cruise ship--nice and relaxing.
Say "Hi," to Chris and Boris for me.
Regards,
James
- E. Bartzokas
- Posts: 114
- Joined: Tue Feb 14, 2006 8:13 am
- Location: Corinth, Greece
James,
You can have multiple previews with FWH, if you change slightly the RPREVIEW.PRG.
More or less, you need to know:
1. If a preview is running already, and if so, you should append to the array of files in the preview, and,
2. Add to oPrvDevice the files that were created.
The "catch" here, is that unfortunatelly, you cannot display landscape and prortait nicely at the same time <g>
Here's more or less the code...
aMultipage holds an array of the files created per each preview, and of course, you'd need to modify the numbering of the created .EMF's.
If you need more code, I'm here.
Adobe reader is much smarter of course... it can display and print correctly, both landscape and portait pages...
-On the personal level...
My wife has the Lupus disease. This is a life-time problem which we fight with chemotherapies, madicines, etc. Unfortunately, it's going to be like this for the rest of her life... No travelling for many hours.
It's Ok to travel by car, if we make frequent stops, eg every couple of hundred of Km's.... So be it... Life is a bitch sometimes...
Kind regards
Evans
You can have multiple previews with FWH, if you change slightly the RPREVIEW.PRG.
More or less, you need to know:
1. If a preview is running already, and if so, you should append to the array of files in the preview, and,
2. Add to oPrvDevice the files that were created.
The "catch" here, is that unfortunatelly, you cannot display landscape and prortait nicely at the same time <g>
Here's more or less the code...
Code: Select all
if ! lMultiRep
... code for non-multiple document preview
else
oWnd:SetFocus()
aPrvFiles := aClone(aMultiPage)
oPrvDevice := aClone(aMultiPage)
oDevice:aMeta := aClone(aMultiPage)
oWnd:cargo := oDevice
nPage := -1 // The function TopPage() will fix the number !
TopPage()
PaintMeta()
oPage:SetText(TXT_PAGENUM+ltrim(str(nPage,4,0))+" / "+ltrim(str(len(aPrvFiles))))
// ? 'DEBUG line 188', 'New Pages added to multiple preview'
Return NIL
If you need more code, I'm here.
Adobe reader is much smarter of course... it can display and print correctly, both landscape and portait pages...
-On the personal level...
My wife has the Lupus disease. This is a life-time problem which we fight with chemotherapies, madicines, etc. Unfortunately, it's going to be like this for the rest of her life... No travelling for many hours.
It's Ok to travel by car, if we make frequent stops, eg every couple of hundred of Km's.... So be it... Life is a bitch sometimes...
Kind regards
Evans
- E. Bartzokas
- Posts: 114
- Joined: Tue Feb 14, 2006 8:13 am
- Location: Corinth, Greece
Enrico,EnricoMaria wrote: Can't you just remove any PRINT/ENDPRINT (even those inside the classes) and issue it manually at the very start and very end of your printing PRG?
EMG
Sorry but I didn't see your reply earlier... Indeed, we could take out the PRINT/ENDPRINT from inside the classes, but it's more complicated, because some of the print jobs, are printed individually (see my message to James Bott)....
I wish there was another way of spooling everything, even to suspend the printer's printing untill all of my print jobs are done, but even so, when the printer driver starts printing again, it will still send individual print jobs to the printer...
Thanks again and my best regards to bella Italia
Evans
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Evans,
>You can have multiple previews with FWH, if you change slightly the RPREVIEW.PRG.
Thanks for the tip. I am going to look into it.
>Adobe reader is much smarter of course... it can display and print correctly, both landscape and portait pages...
Another good point I hadn't thought of.
>My wife has the Lupus disease.
Ah, yes, I know about Lupus. A nasty disease. My empathies.
>It's Ok to travel by car, if we make frequent stops, eg every couple of hundred of Km's....
We have a motor home. It makes long trips much more bearable.
>So be it... Life is a bitch sometimes...
Thank goodness sometimes it isn't too!
>Enrico,
>Sorry but I didn't see your reply earlier... Indeed, we could take out the
>PRINT/ENDPRINT from inside the classes, but it's more complicated,
>because some of the print jobs, are printed individually
Still you could deal with that by either modifying the class so you could set a flag to call endprint or just calling it separately when you print only one report like this:
However, your PDF solution may be simpler for your situation
James
>You can have multiple previews with FWH, if you change slightly the RPREVIEW.PRG.
Thanks for the tip. I am going to look into it.
>Adobe reader is much smarter of course... it can display and print correctly, both landscape and portait pages...
Another good point I hadn't thought of.
>My wife has the Lupus disease.
Ah, yes, I know about Lupus. A nasty disease. My empathies.
>It's Ok to travel by car, if we make frequent stops, eg every couple of hundred of Km's....
We have a motor home. It makes long trips much more bearable.
>So be it... Life is a bitch sometimes...
Thank goodness sometimes it isn't too!
>Enrico,
>Sorry but I didn't see your reply earlier... Indeed, we could take out the
>PRINT/ENDPRINT from inside the classes, but it's more complicated,
>because some of the print jobs, are printed individually
Still you could deal with that by either modifying the class so you could set a flag to call endprint or just calling it separately when you print only one report like this:
Code: Select all
PRINT
report1()
report2()
report3()
ENDPRINT
Or,
PRINT
report2()
ENDPRINT
James