Jim, see below ...

>Peter,
>
>Thanks for the list!!! I will check on a couple of them...
>
>>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).
>
>I dont think im loading any fonts... im using arial from the VFP report writer... i switched from courier new to arial and that reduced the size of my PRN files by half.

In fact this may say something; this morning this already boiled somewher, but now I'd say : how can that be possible ? Two options IMO :
1. The printer IS having difficulties with the (selection of ?) the fonts;
2. It's in graphic mode !
Think of it : Your prn just has the number of exact same tokens. Right ? Now you tell me why the printer is faster ... I'd say because of fewer pixels to print. But (me) be careful here; I just might not know how this works, and possibly the printer may always need to be in graphic mode in order to print a non-fixed font. But hmm, then Courier would be just faster huh ?
I guess your anser might be somewhere in this one.


>
>
>>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.
>
>i thought of this as well but so i sent a small PRN file (75k) and i still get the slow printing..

You might try to look how large the spool file is. I wouldn't know what to do with the conclusion, but possibly its much larger (oh, THAT one would be binary ;)


>
>>8. Consider that you migh be sending graphical data to the printer, or anyway it makes graphics of your data. That's SLOW.
>
>thats been a thought for a while.. are my reports being interpreted as data or graphics????
>
>>9. Consider the resolution the printer is running. 800 is neat, 1600 is overdone, and 300 might work just as well.
>
>the resolution is set to 600dpi... thats one of the control codes being sent to the printer!

Note that no matter graphic or not, this may be the reason why your HP is faster (don't know it); Just try set it at 300 (btw excuse me for mentioning 800 -> stupid). It really makes the world difference (compare 300*300 and 600*600).

>
>>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.
>
>thats why i asked this question!!! i ran the same report load to a slower printer (hp4100n) and it ran twice as fast!!! on a machine thats twice as slow???!!!!
>
>>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).
>
>this is my fear.... that im unable to remove the codes... i guess i was wondering if its possible to remove only the setup and eoj codes but leave all other printer codes alone... any thoughts?

But, what ARE the codes ? This could be two-folded : many many commands of 100 bytes each causing huge overhead opposed to the normal data, or, init-codes the printer is slow at. So this prn is 75K; how large is it for the HP ?
Just for fun, you could use the HP driver on the Canon; it'll avoid all the controls (and print them); it will let you know immedeately whether it'll hickup on the commands; you report may be twice as large, but may come out 10 times faster ...
Oh, now I think of it, this wouldn't be possible, will it ? or ... yes you can, print the report for the HP, catch it in the prn as you did before, and copy that to the Canon, right ?

Regards, Peter