On the CLI, lp and lpr don't print plain ASCII textfiles

[emk2203]

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:

1. Use any ASCII-encoded file. Ubiquitous example could be /etc/bash_completion.d/000_bash_completion_compat.bash.
2. Send to printer with lp -d <printer> <ASCII file>
3. Observe an output of blank pages (Epson ET) or no pages at all (HP LaserJet, Lexmark).
4. 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>.

[zdohnal]

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.

[HinTak]

It should not be necessary - there is /was a texttopdf filter.

[emk2203]

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.

[HinTak]

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.

[emk2203]

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.

[HinTak]

You are missing some fonts. Texttopdf requires a few specific default fonts on the system to work.

[emk2203]

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?

[HinTak]

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.

[emk2203]

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.

[HinTak]

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.

[emk2203]

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.

out.pdf

printer.log

Is that what you meant, or is there more?