1661868 - Remove legacy page-range codepath (and bring the new skip-during-reflow codepath up to feature-parity with it, so it supports non-contiguous page ranges)

Status: RESOLVED FIXED

(Core :: Printing: Output, task, P2)

Description

[Daniel Holbert [:dholbert]]

Bug 1659005 added a new print-page-range codepath that hides pages during reflow (rather than at print time), which for now we're using during tab-modal print preview.

We also have an existing legacy codepath that we use during actual printing.

We should remove the legacy codepath so that we only have one set of logic for handling page ranges. As part of this, we'll need to bring the new codepath up to feature-parity with the legacy one - in particular, we need to support "only print odd/even pages" and printing multiple ranges.

(The odd/even/multiple-page-range scenarios are only exposed via the system print dialogs; so we don't need them [at this point] for the tab-modal print-preview presentation, which is why they don't work yet in our new implementation. But we do need to implement them before we ditch the old code, in order for actual printing via the system dialog to continue to work robustly after the old codepath is gone.)

This bug blocks pages-per-sheet, because our pages-per-sheet implementation will require us to know up-front which pages are skipped when we're laying out multiple pages on a single sheet (regardless of whether we're doing print-preview vs. actual printing).

Comment 1

[Daniel Holbert [:dholbert]]

I should be posting a patch here tomorrow (Tues).

I discovered towards the end of today that the "print odd pages" / "print even pages" part of our page-range support isn't actually wired up to any UI, so it's effectively dead code. Rather than delicately migrating that dead code, I filed helper bug 1669375 to remove it and the effectively-unused APIs around it.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: Bug 1661868 part 2: Unify page-range handling logic, to assume all PrintedSheetFrames should be printed (and let them manage page-range-based skipping during layout). r?TYLin

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: Bug 1661868 part 1: Broaden PrintedSheetFrame's "layout-time" page-range handling to support complex page ranges. r?TYLin

This patch does the following:

• It adds better documentation for the meanings of the page range member-vars
  in nsSharedPageData.

• It copies some logic (with minor tweaks) from the legacy codepath that
  handles page-range support (nsPageSequenceFrame::DetermineWhetherToPrintPage())
  into to the new codepath for page-range support (PrintedSheetFrame.cpp's helper
  function "TagIfSkippedByCustomRange()").

At this point in the patch stack, the legacy codepath is unchanged & still
handles all print operations; and the new PrintedSheetFrame.cpp codepath only
handles page-range-skipping for the print-preview visualization in the
Tab-Modal print dialog. So, this patch effectively gives that print-preview
visualization the platform-support that it would need for complex page ranges
(though that's not available in the UI at this point, so you can't really test
that).

Spoiler alert: the next patch in this series will remove the legacy codepath
entirely, and at that point, the platform-native print dialog's
complex-page-range feature will be backed by the PrintedSheetFrame.cpp code
that's added here.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a4ec51d203be
part 1: Broaden PrintedSheetFrame's "layout-time" page-range handling to support complex page ranges. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/211033e4d7a8
part 2: Unify page-range handling logic, to assume all PrintedSheetFrames should be printed (and let them manage page-range-based skipping during layout). r=TYLin

Comment 5

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/a4ec51d203be
https://hg.mozilla.org/mozilla-central/rev/211033e4d7a8