[Slightly Off Topic] Sending Raw ASCII to Dot Matrix Printer from USB

[rdm2]

Hi all

How do I send ASCII (from a Linux box) to an Epson FX-80 printer? My existing method (lpr) doesn't quite work as it "used to".

I have an Epson FX 80 printer which is "shared" via a Centronics switch between a Beeb and a Linux box. The Beeb, of course, prints perfectly. I need to share the fx80 with a modern PC given the FX80 + paper takes up a lot of room - hence the switch.

The issue seems to be that when I print from the Linux box, it works fine in the sense that it sends "graphics" to the printer. However it sends text (from gedit for example) as "graphics" - i.e. if I change font in gedit, this is reflected in the output. That's all fine - for printing from gedit or any other app - but I really want to print from the command line (via terminal app as opposed to the console. If I do:

lpr textfile.txt

then I do get an output - but it's missing the tails from the gs, ys etc.

I realise this isn't exactly Beeb related but if I asked this question on StackOverflow, I suspect most wouldn't even know what a dot matrix printer is!

Cheers

[scruss]

either

Code: Select all

lpr -l textfile.txt

or

Code: Select all

lp -o raw textfile.txt

Ever since CUPS came along, it's been very hard to send raw binary data to a printer. I class this as a good thing, though: most people will never need to send raw output to the printer, and the results disappoint if you weren't expecting them.

[sweh]

I had to kludge up a dumb printer driver for CUPS to work reliably with USB dot matrix printers.

The code and documentation is here ( https://github.com/sweharris/dumb_usb_printer ). This works just fine with my Epson MX80 (there's an example in the tree), and it works fine with Econet ( https://youtu.be/LioWDLqEs04 )

[scruss]

CUPS can't autodetect very old parallel printers as they don't/can't respond to the printer ID request that CUPS sends. My mid 90's OKI responds to the ID request and CUPS picks the correct driver, but Epson MX/FX printers get stuck.

[rdm2]

either

Code: Select all

lpr -l textfile.txt

or

Code: Select all

lp -o raw textfile.txt

Ever since CUPS came along, it's been very hard to send raw binary data to a printer. I class this as a good thing, though: most people will never need to send raw output to the printer, and the results disappoint if you weren't expecting them.

Just wanted to say thanks for this. lpr -o raw text.txt worked. It's like 1983 all over again!!!

[scruss]

You're welcome. I as just messing about with this on a lower level over the weekend, driving an IBM Wheelwriter 10 Series II typewriter via its parallel port. If CUPS hasn't claimed/been configured to use the parallel port, you can send text directly:

Code: Select all

echo -en 'well \eEhello\eF there!\r\n' > /dev/usb/lp0

That would print the middle word emphasized on this ProPrinter-ish machine.

The parallel port is usually not writeable by regular users, so this (plus a logout/login or full reboot) should give user access:

Code: Select all

sudo adduser user lp

(this is different from the lpadmin group that CUPS uses for config access)

[sweh]

Code: Select all

echo -en 'well \eEhello\eF there!\r\n' > /dev/usb/lp0

This is, essentially, what my CUPS drivers do (the CUPS printer definition uses /dev/null; the driver writes directly)

Code: Select all

#!/bin/bash
{
  cat "$6"
} > /dev/lp_mx80

The dev name is created with a udev rule

Code: Select all

KERNEL=="lp*", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7584", MODE="0666", SYMLINK+="lp_mx80"

This lets me not worry about the original /dev/usb/lp* name in case I plug in more than one USB printer and the order changes

[scruss]

So it's basically a CUPS driver to avoid CUPS? Hmm ...

Because I have to turn the Wheelwriter's printer emulation on and off manually, I don't want CUPS anywhere near it. It's loud enough when it's printing stuff I meant to print, after all

[sweh]

So it's basically a CUPS driver to avoid CUPS? Hmm ...

Pretty much, yeah. I found CUPS didn't work too well with USB printers. It _tried_ really hard, but at the end of the day I found it unreliable. Maybe one print worked and then it hung. So I just said "sod it" and worked around the problem

[scruss]

Whatever works. Personally, I found that the klirichek / zj-58 driver worked with my POS58 USB printers. The only annoyance was that CUPS really likes a defined paper length, so it would always kick out multiples of that length as "pages". Also it was running in graphics mode, which is remarkably slow.

I have a POS printer that can run on anything from 5-24 V. The higher the voltage, the faster it prints. If you can send data fast enough to keep up, at 24 V it's basically a thermal streamer generator --- wheee!