debcrafters-packages team mailing list archive
-
debcrafters-packages team
-
Mailing list archive
-
Message #07135
[Bug 2122775] [NEW] CUPS is disregarding requested orientation and messing up booklet printing since 2013
Public bug reported:
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.
** Affects: cups-filters (Ubuntu)
Importance: Undecided
Status: New
--
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
Follow ups