Printing simple PCL reports to “Windows” printers

[Timothy Kupp]

We run a character-based application on an OpenVMS Alpha that users access from PCs with terminal emulators. From this app, users select reports to print from menus, then files are created with simple formatting and printed to HP printers. The reports are printed either on network (VMS print queues) or local (USB/parallel) printers via VT220 printer controller mode (sending documents back through the telnet connection). The extent of formatting commands used in reports are the PCL commands for underline on/off (ESC&d0D, ESC&d@) and switching between 132-column and 80-column fonts (ESC(10U…, ESC&k0S); pretty simple stuff.

In the good old days, all our HP printers had PCL 5 and understood the above commands. Nowadays, people are trying to use “Windows” or “host based” printers (I don’t know what PCL level these are) that don’t understand the PCL commands that the older or more expensive “office” printers do. The above reports don’t print correctly to these types of printers. I’d like to know what other people have done to solve this. Whatever the solution, I would want it to run on the Alpha box, rather than require something be installed on each PC.

Are there documents that would describe equivalent Windows PCL codes for the above commands? The 80-column or 132-column fonts can be anything as long as they are readable and are understood by the Windows printers.

Are there simple conversion utilities for PCL 5 -> Windows PCL?

I’d like to avoid installing larger programs like Ghostscript to convert files, if possible, but if not, what utilities (preferably free) out there could do this conversion?

[Verne Britton]

AFAIK, there is no solution :-(

... the printer simply does not understand PCL.

When one remote office of mine bought a new printer and we had this exact same problem, I just told them flat out they had to buy another printer (they ended up trading printers with a cubicle that never prints from VMS).

We did have some success sending absolutely plain text ... but that may not do what you need.

OR ... if you have other boxes (Windows, Linux) that could function as a print server (assuming the proper drivers exist for the server in the middle), could you route the output thru them and have that environment do the formatting ?

Verne Britton

[Hoff]

If the currently-available printers lack the necessary features (and in all deference to our hosts here), then it is time to discuss this with the vendor, and with other vendors of printing devices that may (also) have printing devices that (better) meet your requirements here.

[Alex Chadiak]

PCL commands follow a consistant specification with industry wide acceptance to control common printer features ranging from source paper tray selection, font and graphics layout, through macro recording and play back of common form elements

PCL 5 commands begin with the ASCII Escape character and end with the first uppercase letter. Some commands may be followed by binary data or data in another language, typically indicates that the number of bytes indicated by # of binary data such as for an image, character or other bitmap will follow the W. Esc %0B is followed by a number of HP/GL commands which follow a different format.

[Jon Pinkley]

Unfortunately, many inexpensive printers don't have PCL capabilities. The formatting has been moved from the printer to the Windows print driver that the printer manufacturer supplies. So there is no "Windows PCL".

This is similar to the "Windows Modems" that didn't understand the AT command set, and thus couldn't be used on anything but windows computers.

About the best you can hope to do to "support" arbitrary printers that "work" with Windows, is to generate PDF files, and let the PCs print them using the Windows print driver and a PDF reader (acrobat or foxit).

I don't know if it is possible to use ghostscript as a backend to the postscript that DCPS can generate from text files.

We use GraySoft ScriptServer and PDF Broker, but that is not a free solution. PDF Broker runs on a PC and acts like a postscript printer, and is designed to work with ScriptServer (a PostScript Print Symbiont similar to DCPS). ScriptServer can include data in postscript comments that can then be used to pass data to the PDF Broker, so it can do things like distribute documents as PDF attachments to email, which the users can then print to whatever Windows printer they have.

We didn't go this route because we wanted to support windows only printers, we wanted at way to distribute "virtual" paper to locations that we don't have printers attached on our network, and therefore no print queue. PDF is currently the best solution we have found.

Jon

[Andy Bustamante]

Another option may be to revise your reports to html and display with one of the OpenVMS web servers or e-mail with mime. The end user would then need to select appropriate print options for each report.

Andy Bustamante

[Steve Reece_3]

As others have stated Timothy, there's no real fix for what you're trying to do with the printing controlled by VMS and coming out on "Windows only" printers.
PCL is a printer command language that printers understand. VMS doesn't support this directly and will send this out as a text stream, treating it as a plain text printer. What the printer itself does with it isn't known to VMS. In that respect, it is like Postscript, albeit that VMS has DCPS to generate postscript to send to printers.

I suspect that the best target might be to look at switching terminal emulation software so that the printing functionality provided there interfaces better with the Windows-side printer driver. The basic reason that the Windows printers are cheap is that they have no processing capability in them as we would know it - they rely on the Windows driver to generate all of the commands to do whatever the printer's own native language and control requires. There's zero commonality and zero compatibility with anything other than the Windows driver.

Another aspect of this is that the load on the PC processor will increase if you get this stuff to work. If you've got PCs with under-used processors and lots of memory then you should be fine. If you're running Pentium I or 486DX PCs because they have more than enough grunt just to run a terminal emulator then they may come up for replacement as well, meaning that replacing the printer with a more capable one might have actually been cheaper!

Steve

[Jon Pinkley]

For most "inexpensive" printers, the low initial price is soon outweighed by the cost of consumables. The printer companies are not in business to loose money, and the ink/toner is the high margin item that makes up for the low margin printers in the highly competitive low-end printer market.

We have very few low volume printers at work, because they just are not cost effective for us.

And the advantage is that the larger printers usually have a lot more capable print engines as well, most have postscript (or postscript emulators), PCL 5 or 6, and network connections are the norm.

There is much more to the cost of ownership than the initial printer cost.

[Peter Weaver_1]

I have no experience with the product or any connections with the people involved, but http://www.printfil.com/english.htm claims to solve the problem.

Peter Weaver
http://www.weaverconsulting.ca
Winner of the OpenVMS.org Readers' Choice Award for System Management/Performance
http://www.linkedin.com/in/peterweaver