Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#58647 - printing broken on face-up (e.g. inkjet) printers

Attached to Project: Arch Linux
Opened by Frederick Eaton (Herodotus) - Friday, 18 May 2018, 02:47 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 19 May 2018, 00:02 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I've been doing some experiments with the output-order features of CUPS. It is necessary to set the default output order when printing to an face-up printer, because otherwise documents have to be manually reversed.

I found that the various places where default output ordering can be configured (lpadmin, lpoptions, and via the PPD) all seem to affect different clients differently. Here are three ways to set the output ordering:

## set default order with lpoptions
$ lpoptions -dPRINTERNAME -o outputorder=reverse

## set default order with lpadmin
$ lpadmin -p PRINTERNAME -o outputorder-default=reverse

## modify the PPD file
$ sudo tail -2 /etc/cups/ppd/PRINTERNAME.ppd
*DefaultOutputOrder: "reverse"
*% End of PRINTERNAME.ppd, 21673 bytes.

These are the results I get when printing to my inkjet printer:

* `lp`: Ignores PPD line and lpadmin, honors lpoptions setting
* Evince: Ignores lpoptions setting, honors PPD and lpadmin
* Okular: Ignores lpoptions, PPD, and lpadmin

When I use the "Virtual PDF Printer" then I get the same differences between the three applications (although I haven't tried modifying the PPD).

Interacting with the CUPS maintainer Michael Sweet has been difficult. I thought that I would be doing a good thing by identifying, researching, and reporting this problem, but apparently it is not his problem and the documentation is fine. He is very responsive but he responds by immediately closing my bug submissions. Here is the issue on GitHub:

I feel that printing to face-up printers should work correctly by default on Linux, is that not something that other people expect as well?

How does an Arch Linux user deal correctly with a bug like this?
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 19 May 2018, 00:02 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Bug trackers are not the place to figure out how to configure things.
Comment by Doug Newgard (Scimmia) - Friday, 18 May 2018, 14:43 GMT
This sounds more like a configuration question than a bug. I think you're in the wrong place.
Comment by Frederick Eaton (Herodotus) - Friday, 18 May 2018, 20:47 GMT
The problem is that your upstream maintainer doesn't have the bandwidth to maintain bugs for Linux-related issues, even important ones like "inkjets are broken in Linux". This may be a bug in his package, it may be a bug in Evince or Okular, or it may be cups-filters. There may or may not be relevant documentation, but I have not found it. Michael Sweet has just clarified that "We do not document printing solutions for Linux, working or otherwise".

I don't have time to fix these problems, and perhaps nobody around here will have time in the near future. But my understanding of bug tracking systems (correct me if I'm wrong) is that they provide a way to coordinate volunteer efforts by documenting, and providing a forum to discuss, situations which are recognized as being in need of attention.

If you can offer me help with my configuration, then that would be great. But if you think it is only a configuration question then I suspect you have been skimming and not reading. I have a fairly common printer model. I'm looking for a way to configure my printer so that long documents can be printed without having to be manually reversed, page by page, when they come out. According to my investigation, which I documented above, there is no reliable way to configure this across multiple client applications in Linux. To me, in 2018, that's silly and embarrassing. That the current behavior is not even documented seems harder to justify. Users shouldn't even have to use Google, let alone perform exhaustive experiments like I did, to get this to work correctly.

If I were in a position of responsibility here then I would look at forking CUPS and appointing a new maintainer who is able to moderate the discussion of issues affecting Linux users, who has time to share his knowledge about the internals and API of the system, and who is willing to solicit, review, and apply patches correcting these issues.

But please feel free to propose alternate solutions, or kick me off to some other bug tracking system, or close this as WONTFIX. I'm not exactly an active contributor here, and there is a lot that I don't understand about how things are done.
Comment by loqs (loqs) - Saturday, 19 May 2018, 00:02 GMT
The issue you never established upstream with cups was that something cups maintains was the issue rather than cups-filters or some other component.