← Back to team overview

debcrafters-packages team mailing list archive

[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