Input parameters of the PostScript filter. ** Attachment added: "cups_filter_params.txt" https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/2122775/+attachment/5908968/+files/cups_filter_params.txt
-- You received this bug notification because you are a member of Debcrafters packages, which is subscribed to cups-filters in Ubuntu. https://bugs.launchpad.net/bugs/2122775 Title: CUPS is disregarding requested orientation and messing up booklet printing since 2013 Status in cups-filters package in Ubuntu: New Bug description: CUPS is unable to print PDFs with the orientation requested in the system print dialog. It always rotates source PDF 90° CCW if it does not "fit" (nicely, I suppose?) aspect ratio of the output format which is always portrait-oriented. This means that: 1. Landscape-oriented PDFs are always rotated 90° CCW when printed and can never be printed in such a way so they could be viewed normally from a portrait-oriented paper. 2. When 2-up is requested in the system print dialog window, the effective aspect ratio of the PDF which had already been rotated 90° CCW in step 1 is switched, meaning that the file would now become landscape-oriented again. That triggers another round of this "aspect ratio correction" process and the file is rotated once again by 90° CCW to fit the printer's portrait-oriented paper nicely. That results in a 180° rotation of the source file. 3. Lastly, this is what happens when the printer is directed to combine 4 input pages to a booklet, trying to form a portrait- oritented book with 2 landscape-oriented pages of the original source file on one half-page of the output paper: As all 2-upp'ed pages have already been rotated upside-down in step 2, they are also printed upside-down and combined this way. When trying to read such a thing, you are forced to rotate the output from the printer by 180°. But that means that the first page of the resulting book, which was supposed to be printed on the right-hand side of the output paper, is effectively printed on the left-hand side of the output paper. This makes stitching the intended book impossible. The bug was reported back in 2013 here on Launchapd https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1243484 against cups-filters. Sadly, while the status reads "Confirmed in CUPS" (upstream), the link to the upstream bug leads to a bug reported against LibreOffice which has been abandoned and whose state is set to "CLOSED WORKSFORME" - quite naturally, because there is nothing wrong with LibreOffice. The author of the original report states that the bug first appeared in Fedora 19: "I strongly suspect something is amiss with the pdftopdf filter's handling of these options, especially in v1.0.40. Fedora 19 didn't exhibit the same problem until the cups-filters package was brought up to the same version just today." I am able to reproduce this behaviour on Ubuntu 24.04.3 LTS (amd64) with packages cups-filters 2.0.0-0ubuntu4 and cups 2.4.7-1.2ubuntu7.4. It is also reproducible on Ubuntu 18.04.5 LTS with packages cups 2.2.7-1ubuntu2.10 and cups-filters 1.20.2-0ubuntu3.3 and on Ubuntu 25.04 too. If I am not mistaken, the issue could be worked around if the PPD or the system dialog window itself offered an option to reverse page order. But that would mess up page numbers, I suppose, as they are generated in the printer with a proprietary PostScript command. Note: On Windows, the Bizhub 367 prints booklets just fine. But yes, that's using a different driver and possibly one not making use of the PS/PCL API at all. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/2122775/+subscriptions -- Mailing list: https://launchpad.net/~debcrafters-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~debcrafters-packages More help : https://help.launchpad.net/ListHelp
