Bug 704161 - No back side orientation support for duplex printing with "pclm" output device
Summary: No back side orientation support for duplex printing with "pclm" output device
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 9.53.3
Hardware: PC Linux
: P4 normal
Assignee: Default assignee
QA Contact: Bug traffic
Depends on:
Reported: 2021-08-02 16:03 UTC by Till Kamppeter
Modified: 2021-08-16 11:41 UTC (History)
1 user (show)

See Also:
Word Size: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2021-08-02 16:03:33 UTC
PCLm is a streamable raster-only PDF to print on low-resource raster-only printers. As these printers often do not have enough memory to hold the full raster image of a single page they already need to print the page while still receiving data for it.

For duplex printing the front side of the sheet is no problem. The raster data comes with the uppermost pixel line first and this gets printed first, but the problem are the back sides. Dependent on how the printer turns over the sheet it perhaps needs to start printing the page for the back side with the lowermost raster line, so the client has to send the back side upside down.

A PCLm-supporting printer tells in its IPP attributes (response to a get-printer-attributes IPP request) how the back sides of the sheets have to be oriented. The attribute is the "pclm-raster-back-side" attribute which can have values like "normal", "flipped", "rotated", and "manual-tumble". So we need for the "pclm" output device an additional option, like "-sBackSides=..." taking these four values and making the raster data of the back side pages being sent in appropriate orientation (also depending on the setting of "-dDuplex" and "-dTumble").
Comment 1 Till Kamppeter 2021-08-05 13:32:59 UTC
To manage back side orientation in pclm and pdfimage... device I suggest the following:

Use the already existing boolean options -dDuplex and -dTumble and add (for pclm and pdfimage...) -sSheetBack with the 4 choices Normal, Flipped, Rotated, and ManualTumble in this order.

If the user does not supply the appropriate option, use the default:

  -dDuplex    -> false
  -dTumble    -> false
  -sSheetBack -> Normal

Now do this (pseudo code):

   if (!Duplex || is_front_side(current_page)) {
            flipX = false;  flipY = false;
   else {
     if (SheetBack == Normal) {
       if (Tumble) {
            flipX = true;  flipY = true;
       } else {
            flipX = false;  flipY = false;
     } else if (SheetBack == Flipped) {
       if (Tumble) {
            flipX = false;  flipY = true;
       } else {
            flipX = false;  flipY = true;
     } else if (SheetBack == Rotated) {
       if (Tumble) {
            flipX = false;  flipY = false;
       } else {
            flipX = true;  flipY = true;
     } else if (SheetBack == ManualTumble) {
       if (Tumble) {
            flipX = false;  flipY = false;
       } else {
            flipX = false;  flipY = false;

This should do the correct thing.
Comment 2 Till Kamppeter 2021-08-06 11:38:49 UTC
Soory, I got somehow completely confused.

Now I have found the official documentation for backside orientation as part of the documentation of the PWG Raster format:


See sections: CrossFeedTransform and FeedTransform / Table 9


5.1.1 PwgRasterDocumentSheetBack / Figure 5
Comment 3 Robin Watts 2021-08-16 11:41:34 UTC
I have implemented support for doing Duplex/Tumble in the PCLm device in the following commit.

commit 0a0c521d85d0275c0d207a35bd27f0a31d54012b
Author: Robin Watts <Robin.Watts@artifex.com>
Date:   Fri Aug 6 12:59:11 2021 +0100

    Duplex/Tumble/Tumble2 support for PCLm.

This also allows Tumble2 to be set to introduce an additional X flip.

This should allow you to support all the required output types for IPP.

While I expect this to work for PDF, PCL, XPS etc, I have my doubts that this will work for PS files. We manage Duplex in software by changing the 'initial' matrix returned by the device.

Postscript has a (slightly awkward) way of allowing the 'default' matrix for a device to be set and to persist from page to page. Because of this the changed matrix is not consulted on each page. I am considering possible ways around this that give the correct result without breaking our conformance to the Postscript spec.