I thought that Metaframe XP-FR2, using Uniprint drivers, used compression techniques that meant it had similar functionality to the older versions of citrix/tse using external print management utilities such as Screwdrivers or UNIPrint. Am I missing something obvious? Is there any switch or hidden command that is required to ensure that Metaframe XP FR2 uses compression when sending print spool jobs from the server to the client?
The reason I ask is that when checking how much data is being transferred from the server to the client, there does not seem to be a huge improvement in the actual amount of data being sent versus the older versions(s) of Citrix. Yes, the uniprint driver does use an enhanced PCL4 format so if I compare the physical size of the spool file being created by a native print driver versus the uniprint driver, well it is actually smaller.... but the spool file can still be quite large and all that data still gets sent to the client. For example, in testing printing a simple 70k pdf file, the citrix server creates a spool file that is close to 1Mb which then all gets sent to the client as is. I know that spool files are by nature big, but I thought that XP-FR2 was much better now......
In this thread (thread48-487668 a similar result appears to have been found using a word document and I quote: "In the tests we did we had a 70+Kb word document (full of graphics) which generated a spooled print job of 1096Kb from the Citrix box back to the client."
As it is, I will say that the Metaframe Uniprint driver is much better now as far as ensuring you don't have to have multiple print drivers on the Citrix server etc, and so management is much better, and the spool file that gets created using the Uniprint driver is frequently smaller than what would be created by a native driver, but...... it still appears to be sending a huge amount of data from the server to the client when printing, this data (other than the enhancements made by the driver) is not compressed (if I use - say - "zip" on the spool file it will shrink to half the size) during the transfer, and basically I admit to being disappointed in the performance so far. I'd consider using something like UNIPrint, but from the same thread mentioned above, it seems that it may not help all that much..... sigh.....
The size of the spool files can become an issue even on the LAN - if I print a 700k pdf file that has 80 pages of text on it, it creates a 15Mb spool file that gets sent to the network printer via the client. This results in the print job taking up to four times longer to print......
I know I can setup the print queues on the server and have the clients print to them so that would improve the performance, but it would also result in more maintenance. It also won't help with the remote users.....
I suspect that what I'm seeing is as good as it gets, but if anyone has any other suggestions/advice I'm open to pretty much anything!
Cheers
The reason I ask is that when checking how much data is being transferred from the server to the client, there does not seem to be a huge improvement in the actual amount of data being sent versus the older versions(s) of Citrix. Yes, the uniprint driver does use an enhanced PCL4 format so if I compare the physical size of the spool file being created by a native print driver versus the uniprint driver, well it is actually smaller.... but the spool file can still be quite large and all that data still gets sent to the client. For example, in testing printing a simple 70k pdf file, the citrix server creates a spool file that is close to 1Mb which then all gets sent to the client as is. I know that spool files are by nature big, but I thought that XP-FR2 was much better now......
In this thread (thread48-487668 a similar result appears to have been found using a word document and I quote: "In the tests we did we had a 70+Kb word document (full of graphics) which generated a spooled print job of 1096Kb from the Citrix box back to the client."
As it is, I will say that the Metaframe Uniprint driver is much better now as far as ensuring you don't have to have multiple print drivers on the Citrix server etc, and so management is much better, and the spool file that gets created using the Uniprint driver is frequently smaller than what would be created by a native driver, but...... it still appears to be sending a huge amount of data from the server to the client when printing, this data (other than the enhancements made by the driver) is not compressed (if I use - say - "zip" on the spool file it will shrink to half the size) during the transfer, and basically I admit to being disappointed in the performance so far. I'd consider using something like UNIPrint, but from the same thread mentioned above, it seems that it may not help all that much..... sigh.....
The size of the spool files can become an issue even on the LAN - if I print a 700k pdf file that has 80 pages of text on it, it creates a 15Mb spool file that gets sent to the network printer via the client. This results in the print job taking up to four times longer to print......
I know I can setup the print queues on the server and have the clients print to them so that would improve the performance, but it would also result in more maintenance. It also won't help with the remote users.....
I suspect that what I'm seeing is as good as it gets, but if anyone has any other suggestions/advice I'm open to pretty much anything!
Cheers