Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using Debian which is similar to Ubuntu.

They have 7 dot matrix printers, some of which are very old (example), which have worked since 1979 and are faster than many inkjets at printing text.

I believe that it has his own language, since sending text to serial port (port server) prints garbage. However I think is prints only capital English up to 95 ASCII and Greek and the rest up to 127 I think Greek capital. (special chip)

I think that sending English capital letters prints garbage, but I am not sure and will try again.

The other printers are ESC/P compatible and I use a generic Epson driver provided by ghostscript. However, I think that sending text via

lp -dpr1 filename

prints the text as a graphic and changing the printer's font face (courier, times roman, etc) or pitch has no effect.

I am wondering if there is any workaround for this? In AIX they claim that the lp command printed output as text as it prints and Cobol programs send raw text to lp printers. However, in AIX they use some custom filters for the printers and have more options for dot matrix printers.

I would like to know if there is a way to avoid graphics mode for text and change the font face.

The most straightforward approach would be to use no driver, just send ESC/P from Cobol but this requires too much work.

share|improve this question

I haven't tested this (I'm not close to my DEC serial dot matrix printer from the Eighties), but CUPS apparently allows you to send raw jobs to the printer using

lpr -o raw $FILE

Obviously, the job must be in the printer's native command language, whatever it is (plain text should work).

However, some pathology: if the ‘garbage’ is random dots (non-deterministic across print jobs and/or across printers), check the printer's (or printers') character ROMs for corruption. Bit rot is a concern after this long, especially with EPROMs. Since your printers are obviously wearing customised ROMs, this is a likelihood.

If all printers are printing consistently exactly the same output, it's obviously not one printer's ROM. You could check the serial communication parameters are correct. Most printers from the late 70s and early 80s will have a bank of DIP switches to configure that.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.