Sending EPS file from Windows Explorer directly to Printer

[PMSchreiner]

I've been using a variety of applications to generate EPS files for many years. To date, I have in excess of 18,500 EPS files (I just checked).

In the "good old days" all of the users (and myself) were on UNIX boxes, and we just issued "lpr 'filename'" when we wanted to print one of the EPS files...

Then along came Windows...
Back in the early years (until Windows98?) there was an application that I could associate with a "print" action and the .eps extension that enabled the users to right-click on the file they wished to print, select 'print' from the menu, and off they went.

With OS upgrades, the application went away, (We're on WindowsXP now) and the user had no option but to bring up the document in a viewer... The company selected ProductVision Visualizer (VisMockup) as a viewer, because it was so "versatile".... Back when Visualizer was owned by Rosetta Technologies, and was called 'PreView', it worked fine. But as with all things that work, SOMEONE decides that they can be 'improved'. It was bought out by ProductVision, who in turn was purchased by EDS/Unigraphics. Now, thanks to the 'improvements', it's almost unusable.

In order to print a document, the user must bring it into the viewer, manually change the rotation and zoom until it looks acceptable in the 'preview' pane (it does not 'auto-zoom' correctly) then print the document.
Not only is the resulting document inconsistent (the user never can set the zoom factor the same), but it is VERY cumbersome when you have to print 100+ documents for a Technical Documentation package.

So.. enough ranting... What I need it a "simple" method of copying an .EPS file (or multiples thereof) directly to the printer.

I've considered writing a VBScript snippet that will open the user's default printer, read in the eps file and write it to the output device. The problem with this is: a) distribution of the code.
b) I've got about 140 users that I would have to instruct on the procedure for creating the file association.

It seems like there ought to be an easier way to get the job done... I've tried bringing the EPS file into notepad or Wordpad, then printing from there, but it PRINTS the EPS code instead of 'executing' it...

Any ideas?

thanks,

Paul M. Schreiner

 

[tgreer]

Paul,

1st - an EPS file is meant to be consumed by an application, as a placeable graphic image file.

2nd - But, it is PostScript, so some EPS files can be sent directly to some PostScript printers. The uncertainty lies in PostScript language level, and the nature/structure of the EPS (does it contain binary "previews" or undigestible thumbmnails, etc.).

3rd - Windows prints PostScript (and anything, really) through drivers. So what happens when you print from an application, is that the application calls upon the services of a driver and a printer description file, to produce an output stream. So with Notepad, you are producting, when you print, PostScript code that in turn lays the contents of the document (your EPS) on the page. So you're right, the EPS isn't executed, because it isn't being used as an EPS... NotePad sees it as text.

S0. You gotta send either A) print through an application that sees/interprets the EPS properly as an EPS or B) send the EPS directly to your printer w/o going through drivers.

There are definitely ways to accomplish this, including writing, as you say, a vb program to "read" the EPS and "write" it to a port. But you don't give lot of details about your environment. Can you detail your network, printers, etc?



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[PMSchreiner]

I'm not a "network" person, more of an "application" person (DB apps w/Oracle, Ingres, SAP), but I can give it a try.

I was here when they installed thick-Ethernet to connect about 30 UNIX workstations... Since then, the network infrastructure has eveolved beyond anything I would recognize. We currently have about 100 SUN/UNIX (Solaris) workstations and about 900+ Windows PC's (I think 90%-95% of the Windows PC's are now WindowsXP, the remaining on Windows 2000 or WindowsNT).

I believe the print spools are now on (multiple) NT print servers. The UNIX boxes direct print services to the NT server.

From the UNIX environment, I can still use 'lp -dxxxx filename' (or, more importantly, 'lp -dxxxx *') to print the EPS files. This has worked wonderfully for the past 10 years (or more?). Unfortunately (in this case) most of the UNIX users have been 'migrated' to the Windows environment, and no longer have a UNIX account. Consequently, they no longer have the UNIX postscript viewer or print functionality they formerly enjoyed.

I'd considered writing the vb code in WSH, then placing it on a shared drive. Then write ANOTHER WSH script that would create the file association. I could then distribute the 'installation' script to the users without duplicating the vb code on each desktop...

But this seems a bit high-maintenance. If there's some "standard" functionality that I can employ, it would be preferable. I'd considered obtaining a "free" viewer for EPS files, but the network admins frown on installing non-approved applications... even the WSH script is 'pushing it'..

does this help?

thanks,

pms

 

[tgreer]

You don't want to go via the "file association" route. You want to send the files directly to a printer port. The port can be mapped to a network printer.

Windows does have command line arguments. Research the "print" command.

PRINT \\Network_server\\print_share fullpathname

Also look at "copy". You can COPY a file to a port. You can map a local port to a network printer with the "NET USE" command:

NET USE LPT3: \\ServerName\PrinterName /Persist:Yes

Then you can use:

COPY filename LPT3:

Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[PMSchreiner]

Thanks,

Unfortunately, I have a BUNCH of users that if I tell them to "double-click on the filename" they'll ask "Which button do I use?"...

I've even gone so far as putting a post-it on monitors that have a little picture of mouse buttons with labels indicating "Left = Select, Right = Menu"... But then, they don't READ...

I think using the "NET USE" approach would be too much to ask. Especially since A) this came up because one of the more frequent users decided he didn't want to view/print 100 documents, so he wanted to send the all to the printer at once, but couldn't remember what he had to type to change directories when at the command prompt!("should I use 'dot' or 'dot-dot'?") and B) most of the users don't know what the name of their printer is. ("It's the color printer behind the filing cabinet by the door to the boss' office", "Second floor? No, it's on a table, but I can move it to the floor if you think it'll help!")

Then there's the problem that using "PRINT" at the command prompt results in an extra blank page being printed (can't tell if it's before or after), yet UNIX 'lp' to the same print spool doesn't have the same effect...curious....

So...Unless I can find something simpler, I think I'll write the WSH script to read the user's default printer, then read/write the file directly to the spool... I'll look on the internet... there are bound to be examples...

thanks,

pms

 

[tgreer]

I based my reply on your Unix examples.

The NET USE command can be made part of the login scripts... so the users would never have to type that. Plus, it only has to be done ONCE, since the port mapping contains the "Persist" flag.

So every user could have an LPT3: port permanently and invisibly mapped to a network printer.

Then you can create an app (which can be autmatically pushed to every desktop via a login script, depending on your network environment) that contains the "copy" functionality. The app can support drag and drop... or you could create a shared folder on a server where the users drop EPS files, and have a service application running on the server that polls this folder.

As I said, there a number of ways to accomplish this, but the core concept is that you don't want the Windows print mechanism involved in trying to interpret/parse the EPS files... you want the sent directly to a port and/or spooler.



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting