OpenPrinting
On the CLI, lp and lpr don't print plain ASCII textfiles
Before you write the report Read the REPORTING_ISSUES.md file in the main repository and prepare data mentioned there which looks relevant to you issue. -- done
Describe the bug
lp and lpr are unable to get plain ASCII files printed.
To Reproduce Steps to reproduce the behavior:
- Use any ASCII-encoded file. Ubiquitous example could be
/etc/bash_completion.d/000_bash_completion_compat.bash. - Send to printer with
lp -d <printer> <ASCII file> - Observe an output of blank pages (Epson ET) or no pages at all (HP LaserJet, Lexmark).
- If you are on an Arch-based system, the print command results in garbled output.
Expected behavior The file gets printed as a text file with the printer's default font for plain ASCII printing.
Screenshots Photo of Arch output could be supplied if needed.
System Information:
- OS and its version: Ubuntu 25.10, but issue exists for a long time in older versions. Also Arch Linux as a second reference point. While Ubuntu prints blank pages or nothing at all, Arch Linux CUPS prints pages with gibberish.
- Application CLI
- CUPS version 2.4.12-0ubuntu3, or 2.4.14-1 (Arch)
Additional context
If the file is opened by paps and converted to postscript, it prints as expected (paps <ASCII file> | lp -d <printer> -o <options>.
Hi @emk2203 ,
thank you for the report!
Unfortunately I cannot reproduce - my HP printer installed with IPP Everywhere on Fedora 42 (latest CUPS, latest cups-filters) prints the text file within expectations (it has bug for duplex printing via PDF, so I get only the one-sided printout).
So the issue can be with the printers you used, differences between distros, or the mentioned file is different in Fedora (can be recognized as different filetype in CUPS).
Please provide the necessary data mentioned in REPORTING_ISSUES.md - especially matching file from /var/spool/cups, cups debug log and your PPD file - details are in the mentioned file - I can check them and see if there is anything obvious which could help me, but otherwise you will have to contact your distro support.
I have resorted to using paps to have a reproducible printout now. Having the ASCII converted to PostScript seems more straightforward to me, and easier to customize.
For the error report, if Fedora is able to print, it's something which seems to be caused by downstream (Arch and Ubuntu). I am going to investigate further there first.
I believe I was the GSoC mentor for that summer project to add texttopdf to cups filters 15 to 20 years ago. It should just work. Please see why texttopdf is missing.
It is not missing. Both distributions have the filter in /usr/lib/cups/filter. The Arch install prints now from the CLI as desired. Maybe an upgrade happened? Rolling distro model makes it difficult to pinpoint the reason for the change.
The Ubuntu install, however, still doesn't print as it should. By using the proposed sample document instead of one of my real documents, I discovered that it doesn't print white pages. It prints 'white text' except for underscore characters.
Those are printed, the rest is not. Never saw this because I rarely had something with underscores to print.
You are missing some fonts. Texttopdf requires a few specific default fonts on the system to work.
Thanks, do you have a link to where they are listed? I would like to pass that on to the Ubuntu maintainers.
Also, why are fonts needed? Isn't the pure text filter just streaming the ASCII to the printer, together with some printer-specific control codes?
I believe you need the mono font from GNU FreeFonts to make it work. It is "text", which means utf-8, not ASCII. That's the discussion from nearly two decades ago.
Try installing that (as a ubuntu package) and see if it works better.
I installed fonts-freefont-ttf and ran fc-cache -f -v and sudo fc-cache -f -v afterward just to make sure, but the behavior didn't change.
A quick check with fc-list :mono | awk -F: '{print $2}' | sort -u shows the following monospaced fonts on the system:
Courier 10 Pitch
DejaVu Sans Mono
DM Mono
DM Mono,DM Mono Light
DM Mono,DM Mono Medium
FreeMono
Hack
Hack Nerd Font
Hack Nerd Font Mono
IBM Plex Mono
IBM Plex Mono,IBM Plex Mono ExtLt
IBM Plex Mono,IBM Plex Mono Light
IBM Plex Mono,IBM Plex Mono Medm
IBM Plex Mono,IBM Plex Mono SmBld
IBM Plex Mono,IBM Plex Mono Text
IBM Plex Mono,IBM Plex Mono Thin
Inconsolata
KaTeX_Typewriter
Liberation Mono
Nimbus Mono PS
Noto Color Emoji
Noto Mono
Noto Sans SignWriting,Noto Sans SignWrit
Terminus (TTF)
Ubuntu Mono
Ubuntu Sans Mono
A bit annoying that it still doesn't work.
Can you run the bare text to pdf cups filters on both of those files and capture the outputted pdf's and attached them here. I like to have a look at what's wrong with them. It seems that some fonts are embedded or found, but not all.
When you say 'both of those files', what do you mean? I am currently using only the referenced /etc/bash_completion.d/000_bash_completion_compat.bash for testing purposes.
Also, the next step is not clear to me.
I used driverless to find the URI for my printer, and could get a ppd file from it with driverless ipps://EPSON%20ET-3850%20Series._ipps._tcp.local/ > epson.ppd.
Now, when I run /usr/sbin/cupsfilter -p epson.ppd -m application/vnd.cups-pdf -o number-up=2 /etc/bash_completion.d/000_bash_completion_compat.bash > out.pdf 2> printer.log, I get two files which look like they might be of use. I have attached them.
Is that what you meant, or is there more?
I think it is more or less what I meant. I meant both "proposed sample documents" and one of your own real ones. Two in total. It may take some time before I get round to look at the pdfs, however. It was a long time ago I mentored the writing of that code.
This is one of the documents I have for my courses:
The resulting pdf with the command above has 0 B. Attaching it would be futile. I have attached the log file: