1692316 - Duplex "Flip on side edge" / "Flip on long edge" options currently do the opposite of what they say, if you choose landscape mode

Status: RESOLVED FIXED

(Toolkit :: Printing, defect)

Description

[Daniel Holbert [:dholbert]]

Bug 1671702 just landed to expose the kDuplexFlipOnSideEdge and kDuplexFlipOnTopEdge duplex options in our print UI (with strings that match those constants' names).

Unfortunately, these constants are misnamed (at least, they don't entirely map to the behavior that they claim to).

Right now, these enums map directly to native API constants which are about long-edge vs. short-edge binding; e.g. kDuplexFlipOnSideEdge maps to the os primitive for "long-edge binding".

This means kDuplexFlipOnSideEdge will do the right thing (page flips sideways) for portrait mode print jobs, but it does the opposite (page flips vertically) for landscape mode print jobs.

We need to address this before getting people to work on localizing these strings. We have two options to decide between here:

Option (A): keep the strings & enum-names as they currently are, and add some internal logic about whether we're doing portrait vs. landscape-mode, when converting between native constants & our own constants. (i.e. on Windows, our kDuplexFlipOnSideEdge enum would continue mapping to DMDUP_VERTICAL if we're in portrait mode; but if we're in landscape mode, we would map it to DMDUP_HORIZONTAL instead.)

Option (B): rename the options and enums to match the native constants, which are page-orientation-agnostic and just deal with whether the flipping happens at the long-edge vs. short edge.

Option (A) initially seems more intuitive; but it's notable that it would be "going it alone" to some extent. AFAICT, other software[1] all represents this in terms of "long edge" vs. "short edge" flipping, so I'm tempted to just align with established practices rather than trying to define our own easier-to-understand-yet-maybe-more-complex-to-implement way of offering this. But I also haven't done an exhaustive sampling of other software, so there could be other programs out there that do the intuitive option-A-thing which provide some proof that that's a good idea.

[1] I tested Chrome and Edge on Windows 10, and also my own Epson printer driver's "print-details" UI (available via the 'details' button in Firefox's old-style native print dialog)

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

[1] I tested Chrome and Edge on Windows 10, and also my own Epson printer driver's "print-details" UI (available via the 'details' button in Firefox's old-style native print dialog)

One more vote in favor of option B: Safari 14 on MacOS Big Sur uses the "long-edge/short-edge binding" terminology in their UI to configure this (and incidentally, they default to Long-Edge Binding regardless of whether you're in portrait or landscape mode -- i.e. long-edge gets selected in their dropdown UI, if you simply click the "Two-sided" checkbox near the top of their print dialog. This matches Chrome's behavior, and it's also our default behavior as of bug 1689412, in our builds that don't yet have bug 1671702's dropdown menu to choose the binding-mode.)

Comment 2

[Daniel Holbert [:dholbert]]

jfkthame found an HP driver-specific extension panel in Firefox's system print dialog on Mac, which also uses the long-edge/short-edge terminology.

Comment 3

[Daniel Holbert [:dholbert]]

Though we have one counterexample that's closer to our Option (A) -- nordzilla found an HP print dialog on Windows that uses "flip over" vs "flip up", which flips in the appropriate axis regardless of portrait/landscape. If we find more such examples of that terminology, then option A might be more compelling; but otherwise I'm leaning towards option (B), i.e. aligning to what appears to be the rough industry-consensus terminology here.

Comment 4

[Erik Nordin [:nordzilla]]

Attachment: Bug 1692316 - Part 1: Update Platform Duplex Print Terminology r=dholbert

This patch updates the terminology used by the print platform from
the formly used terms of "side edge" and "top edge" to now using
terms of "long edge" and "short edge".

This decision was made to remain congruent with many existing APIs
that use the "long edge" and "short edge" terminology.

Comment 5

[Erik Nordin [:nordzilla]]

Attachment: Bug 1692316 - Part 2: Update Print UI Duplex Terminology r=dholbert,sfoster

Updates the print UI to use the new "long edge" and "short edge"
duplex print terminology that is now used in the print platform.

Depends on D105499

Comment 6

[Erik Nordin [:nordzilla]]

Attachment: Bug 1692316 - Part 3: Document Duplex Printing Constants r=dholbert,emilio

This patch attempts to add a clear explanation and mapping among the
duplex-printing constants that vary across platforms.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/26fd8146640a
Part 1: Update Platform Duplex Print Terminology r=dholbert
https://hg.mozilla.org/integration/autoland/rev/b6ec56449e73
Part 2: Update Print UI Duplex Terminology r=dholbert,fluent-reviewers,sfoster
https://hg.mozilla.org/integration/autoland/rev/6263c7f0613c
Part 3: Document Duplex Printing Constants r=dholbert,jfkthame

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/26fd8146640a
https://hg.mozilla.org/mozilla-central/rev/b6ec56449e73
https://hg.mozilla.org/mozilla-central/rev/6263c7f0613c