While trying to send a text file to the printer via lpr from xterm, the content was corrupted beyond recognition, the cause of which was ultimately traced to the encoding of the file. If I instead process the text with iconv (e.g., iconv -f utf-8 -t ascii//TRANSLIT), then the file is printed normally. Another suggestion I came across is setting the document format (e.g., lpr -o document-format=text/utf8), but this returns the error lpr: Unsupported document-format "text/utf8". I could always alias the lpr command to include processing by iconv, but is there a more general way for native utf-8 support in the CUPS/lpr system?

Edit: My OS is Debian 8 and my window manager is openbox (no desktop environment). I can print this file without any problem from MacOS X as well as from a Debian7/Gnome3 system.

From my current system, I should point out that even after changing character encoding from UTF-8 to ASCII, the newline characters are not respected by lpr, so the lines are concatenated together and printed until the paper margin is reached. After recoding and transliteration with iconv on MacOS X, the printing still works normally (so the newline issue is also specific to my current system).

  • 1
    I haven't deep CUPS knowledge but it definitely should include rules how to detect document type (with MIME type on output) and how to translate any for target printer, this includes rasterisation, forming Postscript or PCL file, etc. Could you please specify your printer type? Did you try a2ps? What encoding is really used on output, when you try utf-8? (I guess it's iso-8859-1)
    – Netch
    Commented Aug 27, 2014 at 4:00
  • @Netch: Thanks for pointing out the a2ps filter. I was not aware of it. The printer in question is an HP4650 scanning laser printer. How can one determine the encoding used by CUPS? The characters actually printed, which bear no discernible relation to the input, included a Greek capital gamma, a capital C with a cedilla, an o with a circumflex, and a Latin capital W and T. Beyond this the failure to respect newline characters results in truncation of output at the paper margin.
    – user001
    Commented Aug 27, 2014 at 17:10
  • Seems that applied encoding is iso-8859-1. You can easily check this using its table. Some searching suggests calling as lpr -o document-format='text/plain;charset=utf-8' will be enough to print as you want, but this doesn't change your CUPS installation default which seems obsolete.
    – Netch
    Commented Aug 29, 2014 at 6:23

4 Answers 4


The same can be done with paps;

#This script converts UTF-8 txt to postscript
paps | lpr
Sometimes you need to specify the prinqueue;

# This script converts UTF-8 txt to postscript
paps | lpr -P lj

Paps does a much better job then cups' texttops.

  • Thanks very much for your reply. I'm aware of paps and wanted to know if there was a possibility of native support within CUPS so that external dependencies needn't be invoked.
    – user001
    Commented Aug 27, 2014 at 17:13

I don't know if you consider HPLIP an external dependency, but here is the official driver recommendation directly from CUPS.

CUPS Printer Driver: HP4650

and Here is the Package info in the Debian Repo:HPLIPS

As Thushi states your system doesn't know how to rasterize the document without using a tool like paps. Installing the hplip package and configuring it at http://localhost:631 to use the recommended driver will solve your issue. For more info, see the SystemPrinting entry at the DebianWiki

  • Thanks. I already have the latest version of HPLIP on my system. I tried to find where one can specify this in http://localhost:631 but I could not find anything about driver selection.
    – user001
    Commented Sep 4, 2014 at 22:33
  • Read Section 4
    – eyoung100
    Commented Sep 5, 2014 at 14:03

I had the same problem and following how-to helped me to fix it:


It's really good. You can even choose a font for text/plain printing like FreeMono or Courier.



You should have something like:

text/plain              application/postscript  33      texttops

in your /etc/cups/mime.convs file. So, I suppose that what needs to be done is to fix the texttops filter. Under Debian, it is /usr/lib/cups/filter/texttops, which is a shell script that uses the texttopdf filter and the pdf2ps command. You can try to replace the texttopdf/pdf2ps invocation by paps, but note that the arguments are not the same. The minimal (since the text is provided to the standard input and the ps result is sent to the standard output) would be a line just containing:


but you may want to add options, e.g.:

paps --font='Monospace 10'

Note: I have not tried. Just speculation...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .