The smallest spooler file size

[jasee]

XP operating system. HP printers (directly connected by ip address)
I want to send the smallest possible prints to my laser printer. I've
changed the resolution/quality on the printers to be the smallest possible.
I've tried printing to postscript (ps), pcl5e. or pcl6 printers.
For text and a simple word document (one font). There is no difference in
spooler size. For a complicated word document (with images), the ps file
size is a lot smaller. Pcl5e and Pcl6 are the same. Its the same for pdfs.
For instance with ps, one file was only 8.2mbytes, however it was over
30mbytes with pcl.

It seems to me that it is usually preferable to use ps drivers if you want
to send the smallest possible file?

(I'm testing to try and optimise slow terminal server printing, so physical
speed of printing is not important)

 

[Graham]

XP operating system. HP printers (directly connected by ip address)
I want to send the smallest possible prints to my laser printer. I've
changed the resolution/quality on the printers to be the smallest
possible. I've tried printing to postscript (ps), pcl5e. or pcl6 printers.
For text and a simple word document (one font). There is no difference in
spooler size. For a complicated word document (with images), the ps file
size is a lot smaller. Pcl5e and Pcl6 are the same. Its the same for pdfs.
For instance with ps, one file was only 8.2mbytes, however it was over
30mbytes with pcl.

It seems to me that it is usually preferable to use ps drivers if you want
to send the smallest possible file?

(I'm testing to try and optimise slow terminal server printing, so
physical speed of printing is not important)

I think we need nore details.

If you are using terminal services, presumably this is running on a server?

What is the printer connected to? Conventionally it would be connected to
the server. All the print processing takes place on the server. Clients
which connect to the domain controlled by the server then rely on the server
for all the print processing. The client sends the document to the server
in a format private to M$ - the server then converts it to the printer
language.

If you use terminal services, all the communication between the application
(Word) and the printer takes place on the server. All that terminal
services achieves is to replicate the user's screen from the server to the
remote client. It is as if the user were sitting at the server and logged
on to it. Nothing whatever to do with printing passes over the terminal
services connection.

I cannot see that the choice of printer language will affect terminal
services performance.

 

[William R. Walsh]

Hi!

If you are using terminal services, presumably this is running on a

server?

The original poster mentions XP, and XP does come with a scaled down (single
user) version of Terminal Services.

What is the printer connected to?

The OP says "directly connected by IP address". Sounds like a JetDirect or
similar network controller is attached to the printer.

All the print processing takes place on the server.

Depends on a variety of factors. For a "dumb" printer, that is true whether
the operating system is server or workstation grade. For a "smart" printer
(and I would think anything capable of understanding multiple printer
languages like the OP talks about would qualify) the processing happens on
the printer. The computer only controls and manages the spooling process and
hands out more data as the printer is ready to accept it.

I cannot see that the choice of printer language will affect terminal
services performance.

It won't*. But if the network is slow, it makes sense to send a smaller data
set to the printer. I think that's what the OP is getting at. Although
PostScript may be processed more slowly at the printer, it looks to be the
smallest and most efficient method of printer control to use.

* Microsoft's own "Remote Desktop Connection" software for connecting to XP
systems and Terminal Servers does allow for the mapping of locally installed
printers to the user's Terminal Services session. With a setup like this,
print data would surely be transferred using the RDP/Terminal Services
protocol back to the locally attached printer on the computer that is being
used to access Terminal Services.

William

 

[jasee]

I think we need nore details. If you are using terminal services,
presumably this is running on a server?

Sorry it's a bit of a red herring really. I'm trying to solve a slow
terminal server printing problem. But I'm trying to minimise the amount of
data that's sent across the network (as a start) So I'm investigating
printing locally. In fact all 'my' local printers are all connected by ip
address. So they spool on my machine.

What is the printer connected to? Conventionally it would be connected to
the server.

That would be lnot very useful. Terminal services are often connected to
over a vpn in which case, you obviously want your locally connected printer
to print. Alternatively you may connect from another domain where you don't
want to print to the terminal servers printers directly installed on the
server. Alternatively you may connect via a cirtix server (though this is
rather different, you still usually want to be able to print locally)

Nothing whatever to do with printing passes over the terminal services
connection.

In fact, in the cases mentioned above the raw data is sent at least three
times over the network, so it's essential (I think) to minimise the amount.
Although (of course) the print job is spooled on the terminal/citrix server
first.

 

[Graham]

Sorry it's a bit of a red herring really. I'm trying to solve a slow
terminal server printing problem. But I'm trying to minimise the amount of
data that's sent across the network (as a start) So I'm investigating
printing locally. In fact all 'my' local printers are all connected by ip
address. So they spool on my machine.

That would be lnot very useful. Terminal services are often connected to
over a vpn in which case, you obviously want your locally connected
printer to print. Alternatively you may connect from another domain where
you don't want to print to the terminal servers printers directly
installed on the server. Alternatively you may connect via a cirtix server
(though this is rather different, you still usually want to be able to
print locally)


In fact, in the cases mentioned above the raw data is sent at least three
times over the network, so it's essential (I think) to minimise the
amount. Although (of course) the print job is spooled on the
terminal/citrix server first.

I still don't understand the configuration.

You have a workstation running the terminal services client. At another
location you have a server running the terminal services server. There is a
VPN connecting the two.

Where physically is the printer? Is it at the server site, connected to the
network supported by the server?

Or is it at the workstation site, connected to the same network as the
workstation?

How is the VPN between the two sites implemented? Is it via routers, or
using the built-in client in the PC?