Hope your product can do what I need! (PCL output to HP Printer)

[Lee-LA]

Congratulations on your new product! I have only been looking for it for about 10 years! I'm not quite sure from your descriptions and your manual whether you are there yet or not, but you are definitely close. As a retired computer engineer who has worked with printers for three companies (Xerox you have heard of, but probably not Peerless Systems or Local Data; both of the latter are gone), I was thinking I might have to do myself what you have already done most elegantly. (On your FCC certification, if you need Class B, you may need room for some ferrite beads or beads-on-wires to attenuate UHF. With a plastic case, even plating won't give you enough shielding. I don't know how easy it is with hobbyist-type products like yours--Class A is much easier to meet. I also don't know how RF-noisy the Raspberry Pi is.)

My need is driven by the same basic problem that you are answering: Nobody makes a laser printer that accepts a Centronics interface. All I need from the laser printer is text of high quality, no graphics at all. So I don't need a smart interface, only one that accepts bytes from the Centronics interface and sends them to the USB port of an HP printer. The design of HP PCL is such that an unmodified byte stream is all that the printer needs to receive. What I don't know (but you may know) is whether Linux on the Raspberry Pi can handshake with the printer on power-up, and then open its mouth and transparently send Centronics bytes to its USB. Supporting the Centronics status lines would be ideal but I could make do without support for Paper Out and other printer messages; they're on the printer control panel.

For the bigger picture, here is the application story. It starts in 1976. That is when I got access to a Wang Word Processor at work. One of the first commercial word processing systems, it was based on the Intel 8080, had 8-inch floppy disks, a Diablo 20 char/sec wheel printer, and its own CRT and keyboard. It had only been 8 years since Doug Engelbart stunned the Fall Joint Computer Conference in San Francisco with a live demo of the first interactive full-screen word processing system--he got a standing ovation from a big hall stuffed with people--and here was the Wang in 1976, even better. The user interface was remarkably good and the product did well for quite awhile. The next year, my wife passed the California Bar examand opened her own small law office the year after. She made do with an electric typewriter but was frustrated by tedious error correction, especially after seeing the Wang. Hobbyist-grade PCs were making their appearance, but WordStar, the best available hobbyist word processing software, was atrocious junk. Then the IBM PC came out. Everything changed. A smart software company made a deal--an insurance company wanted Wang word processing, but not at Wang's price. Could they emulate the Wang on IBM PCs? You bet they could! They did a perfect emulation--faster, of course, on the PC--and they kept the rights to sell the software to others, which they soon did. It was called MultiMate.

We drove an hour across LA to the first place that was selling MultiMate and tested it. I went out on a limb and spent $3000 for a PC, $500 for a typewriter-based printer, and $200 for MultiMate. It was money well spent. My wife learned MultiMate well, though she is totally not a technical person, and over time has built a library of documents that is irreplaceable. Now she is the the last MultiMate user! That company is long gone, its successors too. I have been supporting her--first with an HP LaserJet Plus, which understood downloaded fonts and lasted 15 years. MultiMate went from PC DOS 2.0 to PC DOS 3.3 but no further, because MultiMate software went no further. We went from floppies to hard disks to hard disks that need special formatting to work with MultiMate. I have backup hardware for everything except for the LaserJet 2100 printer, the last HP with a Centronics interface. There's no way to support a USB interface on DOS 3.3; the LJ2100 is showing its age. As a sole practitioner, she'd rather keep using what she knows. She doesn't have to think about computer details; thoughts stream from mind to fingers to page effortlessly. I have Googled for your product before (never found "the $600 one" you mentioned) and am glad to find yours! I hope we can be your customer!

I can understand your focus on Epson printers but that probably won' t work directly for us. MultiMate supports Epson printers, but I am not sure whether Epson printers ever supported multiple fonts, or even the notion of fonts. I'm sure that Linux supports HP printers quite well, but I do not understand what it would take to close the gap between your Centronics input capture and the Raspberry Pi USB output stream. Using PDF as an intermediate won't work, because the PDF software cannot be allowed to impose its formatting and pagination--and delays--on a stream that is already in ready-to-use form from MultiMate for an HP printer. We are not trying to dearchive what's on MultiMate--I can do that in other ways. I need a hands-off, transparent, straight-through, near-real-time adapter.

Probably I do not understand your product well enough. Can it do what I want? Can I tweak it or write software to make it do what I want? Would having a Linux wizard for an afternoon take care of the problem? I can code in C, Fortran, Visual Basic, and MATLAB; would that help? Is your software intended to be open source or not? Perhaps what I need is what some other folks would like. I would appreciate a response from you very much. Thanks, Lee.

[RWAP]

Thank you for the very interesting post and background. I am the main software developer for the Retro-Printer Module and my background is actually that I was originally a solicitor, working in an office in the late 1980s where yes, they too still used Wordstar and 8" floppy disks - although those were on the way out and they moved to WordPerfect (which was, in my opinion, just as bad).

In fact the first time I used a PC with WordPerfect, I wrote them a letter explaining that if you did X, Y and then Z, the software crashed and the original file was corrupted. Their answer was simple - "That is not how the manual tells you to do that". With several years under my belt testing and reviewing software at that point (and knowledge of Z80 and 68000 machine code programming, plus Sinclair BASIC (SuperBASIC) programming) I was less than impressed.

I had not written a C program until the early 1990s, and in fact my first effort was to take someone else's Epson ESC/P2 driver and re-write it to support 720dpi and the higher TIFF and Delta Row compression methods.

Anyway, turning to your queries.

I'm not quite sure from your descriptions and your manual whether you are there yet or not, but you are definitely close.

At the moment, we in the midst of finalising the hardware and case design with a company with plenty of experience in producing HATs and cases for the Raspberry Pi. They have confirmed FCC and CE compliance will be met.

We have also been testing the hardware with a range of different single board computers which offer a trade off between cost, speed and availability - so the HAT has been verified with the Orange Pi PC, Odroid C1 and C2 and the Banana Pi (as well as Raspberry Pi dual and quad core versions).

The software is complete so far as we need for the initial release and we do not intend releasing it in its entirity as open source.

We utilise a range of filters for converting captured code and have released a version of the Epson ESC/P2 filter as open source (https://github.com/RWAP/PrinterToPDF/). We are planning to further enhance this from the point of view of speed, support for further fonts (such as the various international fonts built into Epson printers) and user-defined characters.

There is a simple PCL filter at present which utilises GhostPCL (once installed by the user) to convert the captured data to PDF.

We do not deal with feeding back any printer statuses to the main PC unfortunately. This is mainly because the restrictions imposed in using the Raspberry Pi (or other single board computer) mean that our software has to mainly focus on capturing all incoming data. Conversion and printing then takes place at much lower priority in the background (or when the incoming data stream is quiet). As a result, by the time the printer status (paper out etc) was noticed, it would be much too late to notify the connected PC.

I'm sure that Linux supports HP printers quite well, but I do not understand what it would take to close the gap between your Centronics input capture and the Raspberry Pi USB output stream. Using PDF as an intermediate won't work, because the PDF software cannot be allowed to impose its formatting and pagination--and delays--on a stream that is already in ready-to-use form from MultiMate for an HP printer.

We had not considered this - but you are correct, in that if a HP PCL printer is attached to the USB port, there is no actual need to convert the captured PCL in such an instance.

We have, however, already proved that we can send a captured data stream direct to the USB device without needing to do any conversion or use the built in CUPs Linux printer to dump the output. We actually do this as part of our parallel project, the RWAP Interceptor module (where the single board computer sits in line between a computer and a connected USB printer).

We would therefore need to create a new version of the existing PCL filter which incorporates a flag to say whether conversion of the data is required, or whether it should be sent direct to a connected USB printer.

Ideally, however, you would also be able to direct the captured PCL data direct to a network printer; so it might make sense to still use CUPS rather than dealing with the USB port directly.

I understand that CUPS should be able to send raw data without any processing using the command:

Code: Select all

lp -d printer_name -o raw filename

The best approach would therefore need to be checked and developed once you had a module to hand - so at that point, I would be willing to share the PCL filter code for development and testing purposes.

[RWAP]

We have actually now created a new test version of the software (ready for when you have suitable hardware).

This incorporates two different methods of doing this:

a) usb passthrough - incoming data is simply echoed to the /dev/usb/lp0 device (assuming CUPS has not grabbed it for your HP printer!). No data is stored on the Retro-Printer using this mode, so it is the most direct

b) output printer = raw - incoming data is still parsed before being sent to the default CUPS printer with the command

Code: Select all

lp -d printer_name -o raw filename

This allows for the captured data to still be stored on the device (as a pcl file) and even converted to a PDF if you have GhostPCL installed.

The only downside here is that we have to wait until all incoming data has been captured before we can send it to the printer using CUPS. It does, however, allow you to use network printers rather than being limited to a printer connected directly by USB.