Printing to Unsupported Client Printers with a free PDF Creator

Nice going on the solution.
1 question though; is the file send from server to client over the virtual channel (ctx = \\client\c$\whatever TS = \\tsclient\c$\whatever)  or is the pdf tool not session aware and does the path need to be scripted like \\hostname\c$\whatever ?
 
Brian; can you send me Chris Cairns email adres, so i can chat with him about it?
 
Stefan
http://www.printingsupport.com

Were you aware that EOL Universal Printer has supported PDF-based printing since 2001? Back then, the only "universal" printing solutions on the market were ThinPrint and UniPrint. Both products relied on client drive mapping to transfer the print job from the server to the client. However, virtual channel support was built into EOL Universal Printer since the very first release. "Print to file" was also there since the first release, as well as email support via SMTP and MAPI. That was the main reason for using PDF as opposed to EMF, even though support for EMF (smartEMF) is now available as an option. Because virtual channel support was built into the product, RDP-based printing was also supported right from the beginning. Windows 2000 TS does not support client drive mapping, so neither ThinPrint nor UniPrint could support RDP environments at the time. It took both companies a few months to catch up.
 
There's a lot more to "universal" printing than converting a print stream to PDF, not to mention that this freebie is infringing on some pending patents.
 
What makes a printing solution truly universal is its ability to inherit the features and capabilities of the client-side printer (bins, margins, paper sizes, color, resultion, and about 20 or more essential features). It's like purchasing a universal remote control to program into it the functions of 5 manufacturer-specific remote controls. We've been at it for six years and one thing I've come to notice is that many folks out there tend to use the term "universal" a bit too loosely.
 
Peter 

Peter,

These rather simple and "non functionality rich" tricks serve a special market segment.
It's the customer that has no budget for a printing solution and probably has a single end user at home with cheap a host based radio shack printer. (usually some type of manager)
At that point the manager needs a new printer, the company needs to buy a 1000$ printing solution, or the manager needs to use this pdf construction.
The choice is simple; the first option is th epdf, and the second option is the 70$ instead of the 50$ printer.

No market share is lost for any printing vendor with this pdf solution. The lost functionality is just to much.
 
Stefan
http://www.printingsupport.com 

Stephan,
 
Agreed. But my experience has shown that the "lost" functionaliy comes into play in most cases, even when the customer's printing requirements appear to be simple on the surface. UniPrint (or whatever their name is these days) is attempting to patent their solution; that's why I wanted to put this warning out there. 
 
Peter 

Stephan,
 
Agreed. But my experience has shown that the "lost" functionaliy comes into play in most cases, even when the customer's printing requirements appear to be simple on the surface. UniPrint (or whatever their name is these days) is attempting to patent their solution; that's why I wanted to put this warning out there. 
 
Peter 

For us it is just a great way to get a few users up and running quickly.  We don't have a large user base and always end up with a few that bring their own cheap printers.  We require that all new printer purchases are in a supported list.  
 
This solution provides the user not only a quick work around but allows them to save print jobs to PDF and TIFF direct to the server or local workstation which is often a request.