You are not logged in.
I have a problem with my inkjet printer. I can't get it to consistently print documents with correct page order. From my experiments, this seems to be a problem with most inkjet printers on Linux, in that CUPS provides no way to specify the default page ordering for a printer across all client applications, and in that inkjets tend to print pages face-up which requires that pages be output in reverse.
The CUPS maintainer Michael Sweet does not provide documentation for Linux, nor does he help answer questions relating to CUPS on Linux. https://github.com/apple/cups/issues/5315
Arch bug tracker person Doug Newgard proclaims that bug trackers are not used for problems involving software configurability. https://bugs.archlinux.org/task/58647
Is there a way for users to report general problems to someone who is in a position to coordinate fixes? As far as I can see, there is little motivation for anyone to invest time in this problem at present, as no one responsible will admit that it exists, or even give evidence of understanding it.
Offline
as no one responsible will admit that it exists, or even give evidence of understanding it.
The onus is on you to provide evidence that it does exist.
In my experience, CUPS can be frustrating at times, but the sort of bug you are describing would be a showstopper and, in both corporate and home setups, I have never seen anything like what you describe.
Offline
Please also reconsider your proposed solution of arch forking cups. Where would arch find the resources to provide a better fork of cups
than upstream not to mention IP issues and it going against arch's basic philosophy of fixing upstream issues upstream.
Offline
Skimming the cups bug, it sounds more like an issue with some GUI frontends (or particular clients) overriding the lpoptions outputorder key (raise the cups debug level to figure what's going on)
In case there's desire for filter-based workarounds, upstream is https://wiki.linuxfoundation.org/openpr … ps-filters
Offline
I love how apple closed that issue as "too heated" merely for asking one polite question too many.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
I hope this isn't the infamous "necro-bumping".
I submitted the bug to cups-filters and some changes were made:
https://github.com/OpenPrinting/cups-filters/issues/47
I think there still may be a problem with printing under Okular, I'm still waiting to hear back from Till Kamppeter at cups-filters.
A lot of the trouble I had debugging this was with the fact that CUPS does not document the interaction between 'lpoptions' and 'lpadmin', nor does it document how each applies to command-line vs. GUI printing. As I said before, Michael Sweet has stated that he does not provide documentation for Linux. He is not willing to address problems with the existing manual pages. Had this not been the case, I would have gotten farther along in my investigation before running out of energy.
I wanted to respond to this comment in particular:
> Please also reconsider your proposed solution of arch forking CUPS. Where would arch find the resources to provide a better fork of CUPS than upstream not to mention IP issues and it going against arch's basic philosophy of fixing upstream issues upstream.
"IP issues" - I was under the impression that CUPS is free software, isn't it under an Apache License? Or what IP issues are you referring to?
"Where would arch find the resources to provide a better fork of CUPS than upstream" - it's possible that you wouldn't be able to, however I think that you would have better chances if you admit that there is a problem in need of a solution. From reviewing the various issues on the CUPS github issue tracker, I can see that other users have been in a similar position to myself. On the other hand if Arch maintainers don't admit that anything needs to change, then I doubt that anyone is going to want to risk investing time in helping us.
Those are just some thoughts about this particular experience - I'm not very involved here, and maybe one would expect Debian or Ubuntu or some distribution with a different philosophy to take the lead. But Arch is what I happen to use at the moment. Also, I don't maintain anything myself; maybe if I did then I would have better insight into these things.
Offline
> Please also reconsider your proposed solution of arch forking CUPS. Where would arch find the resources to provide a better fork of CUPS than upstream not to mention IP issues and it going against arch's basic philosophy of fixing upstream issues upstream.
"IP issues" - I was under the impression that CUPS is free software, isn't it under an Apache License? Or what IP issues are you referring to?
cups 2.3 is under the Apache License 2.0 cups 2.2 is under the GPL 2.0, that does not cover the licensing of the name cups or any graphics / logos similar to when Debian forked firefox to iceweasel.
"Where would arch find the resources to provide a better fork of CUPS than upstream" - it's possible that you wouldn't be able to, however I think that you would have better chances if you admit that there is a problem in need of a solution. From reviewing the various issues on the CUPS github issue tracker, I can see that other users have been in a similar position to myself. On the other hand if Arch maintainers don't admit that anything needs to change, then I doubt that anyone is going to want to risk investing time in helping us.
If your post was aimed at the arch package maintainers then posting to the forum is much less likely to be seen by them than the mailing list.
Offline
Ah, that's helpful. I didn't know about the mailing list. Well, loqs, you seem like you know stuff, do you think I should send this to the mailing list?
Offline