>Hi all....
>
>I've got a program thats sending 3 reports per customer (at 2000 customers..) to PRN files, then i merge all the PRN files into a master prn file and then send it via the COPY /B command to a Canon high speed/capacity printer which should be printing at 60/75 ppm. (roughly)... i do this to allow the users to reprint claims and customer info without having to wait through the print loop again...(also to archive the reports).
>
>My problem is that it's very slow... maybe 1 sheet of paper every 2-3 seconds. at this rate it will take over 13 hours to complete. i changed all of my courier new font to arial and that reduced the size of my prn file by half.. that helped a little in loading to the printer but i noticed that for every report in the prn file theres printer driver init code for the canon printer as well as an EOJ line...
>
>I think this is what is slowing my jobs down.... loading and reloading of the driver info...so my question is... is there any way to remove this printer driver init/EOJ code after the first page???? i've tried to programatically remove what i thought was the extent of the code but because its in binary it's hard for me to know whats driver info vs report data...
>
>any thoughts??
>
>thanks in advance,
>
>Jim

Jim,

1. To my expectation the loading of fonts into the printer will take most of the time. I don't know whether this is the case, but if so, don't do it (i.e. use an existing font in the printer).

2. It is very well possible that you have some bottleneck from the server to the printer. 100Mb already might do the job when you haven't yet. Think of boxes in between too (one line -> several printers), and realize that it's just a LOT of data going to the printer.

3. How come the data you see is binary ? a .PRN just isn't, or anyway needn't be. We so similar, and it's jusr readable print control codes in there. Unless ... you don't recognize them. So, do you recognize the normal print data ? if yes, fetch the printer's manual, and look for the codes.

4. When removing code from the top of the individual prn's, realize that you may need to be at the bottom as well. I mean, when there is reset-code at the bottom, that should be eliminated just as well. But for the last one of course.

5. I'm not sure whether you use some kind of reporting tool. It yes, you are rather out of control. If no, you might consider controlling the printer in raw mode, and you are in control of everything.

6. Think of working the other way around : have all in one large report, direct it to the prn again, but devide it afterwords by some lowlevel oparation. You possibly need some additional "heading" info in the indidual prints to recognize the devision points. I'd go for this one, IF the additional control code were the problem at all ...

7. A Canon (in general) is a printer which will fetch the nearest font (with size and type) to what you wanted. I'm not sure at all, but that might take time. So, try to steer the printer with something for sure it can match 100 %.

8. Consider that you migh be sending graphical data to the printer, or anyway it makes graphics of your data. That's SLOW.

9. Consider the resolution the printer is running. 800 is neat, 1600 is overdone, and 300 might work just as well.

10. Test your report on just another printer in order to see what's holding up. Personally I doubt it's the additional codes, and I think the printer can't cope 1:1 with what you want (okay, OR it's the uploaded fonts). So it's converting. By having tests on another printer, you might find out.

11. Start with the prn's as created by VFP; there really won't be ninary data in there, or you do something I don't know of. So again, if you recognize your normal print data, fetch the manual, but now in order to see what's happening in there. You will learn what to do, or see that nothing can be done (report-generator with too few hooks).

Jim, above is in random sequence, so try to start with the one which takes the least time and may help the most. But that's obvious.

HTH,
Peter