Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
This extends the measuring reflow mechanism from multicol (Bug 1994346) to
printing scenarios. When absolutely positioned elements exist, we now perform
an initial measuring reflow with an unconstrained page height to compute
unfragmented positions, sizes, etc.
Each frame type (nsPageSequenceFrame, nsPageFrame, PrintedSheetFrame,
nsPageContentFrame) has their own logic to calculate the available size for its
child, and they do not derive the size from their own reflow input's available
size. To avoid substantial refactoring, this patch checks
`mIsInFragmentainerMeasuringReflow` and overrides the available block-size to
unconstrained when running a measuring reflow.
Differential Revision: https://phabricator.services.mozilla.com/D284550
We can just use `mFrameConstructor` to call `GetRootFrame()`. In order to do so
while keeping `PresShell::GetRootFrame()` as a inline method, we need to include
`nsCSSFrameConstructor` header in `PresShell.h`, and remove `PresShell` header
in `nsCSSFrameConstructor.h`. That means we can no longer inline
`RestyleManager()` since it needs to access `PresShell`, but it's OK since
`RestyleManager` is used only in the frame constructor, and is probably not in
the hot path.
Differential Revision: https://phabricator.services.mozilla.com/D210670
The various prefs related to CSS page size etc. have gotten confused. That
said...
The pref check in `PrintedSheetFrame::ComputeSheetSize` is really a redundant
early return, since the values returned from the `ComputePageSize()` and
`GetPageOrientationRotation()` calls that follow it are pref guarded.
Similarly, the gfx checks are just belt and braces given the sheet size
computation is already pref guarded, and it's the value from that that's being
fed through to these locations.
Nevertheless, let's leave these checks in for now, but just guard them with
the actual pref that's supposed to control whether the pages in PDF output
can have different sizes.
Differential Revision: https://phabricator.services.mozilla.com/D195743
The old name is potentially misleading now that we implement 'page-orientation'
since that provides a new mechanism by which pages could end up orthoganal
to the sheet, but this method is very specifically about pages-per-sheet
induced rotation.
Differential Revision: https://phabricator.services.mozilla.com/D193989
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that when we output PDF files the pages visually have the correct
orientation.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This commit keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet), if necessary, to make best use of the space on
the sheet. (We can't know what orientation any subsequent pages on the sheet
will have, so we assume the same orientation as the first one.)
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that when we output PDF files the pages visually have the correct
orientation.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This commit keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet), if necessary, to make best use of the space on
the sheet. (We can't know what orientation any subsequent pages on the sheet
will have, so we assume the same orientation as the first one.)
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that when we output PDF files the pages visually have the correct
orientation.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This commit keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet), if necessary, to make best use of the space on
the sheet. (We can't know what orientation any subsequent pages on the sheet
will have, so we assume the same orientation as the first one.)
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.
None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.
Differential Revision: https://phabricator.services.mozilla.com/D179423
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that the pages in the PDF files that we output are correct.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This change keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet) if necessary to best place the page to make
maximum use of the space.
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.
None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.
Differential Revision: https://phabricator.services.mozilla.com/D179423
OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.
None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.
Depends on D179395
Differential Revision: https://phabricator.services.mozilla.com/D179423
This code doesn't change behavior itself. The same sheet size is cached on all
sheets. Patches for future bugs will change that.
Differential Revision: https://phabricator.services.mozilla.com/D179395
This code doesn't change behavior itself. The same sheet size is cached on all
sheets. Patches for future bugs will change that.
Differential Revision: https://phabricator.services.mozilla.com/D179395
Prior to this patch, we would place the pages edge-to-edge, then center that
collection of pages in the sheet. Now we create a grid of equally sized cells
that uses as much of the sheet as possible. Each page is then centered in its
grid cell.
Differential Revision: https://phabricator.services.mozilla.com/D179092
When splitting out the code for bug 1830900 I missed this rather important line.
That bug changed the code to store certain values on a per-sheet basis, but
forgot to include this line to calculate them for all sheets (as opposed to
just the first sheet).
Differential Revision: https://phabricator.services.mozilla.com/D178347
When splitting out the code for bug 1830900 I missed this rather important line.
That bug changed the code to store certain values on a per-sheet basis, but
forgot to include this line to calculate them for all sheets (as opposed to
just the first sheet).
Differential Revision: https://phabricator.services.mozilla.com/D178347
To support mixed sheet orientations when printing, these calculations need to
be per-sheet. (This change will also be necessary further in the future when we
support saving to PDF with different sheet sizes.)
Differential Revision: https://phabricator.services.mozilla.com/D176914
The intention is to allow PrintedSheetFrame::Reflow to access the page style
prior to reflowing its child so that it can decide whether to apply page style
to the sheet (in the case of one page-per-sheet). This will happen in a
subsequent bug.
Differential Revision: https://phabricator.services.mozilla.com/D173773
This lets users e.g. print-to-scale where it matters.
Custom margins are still clamped to unwriteable margins, even when all zeroes,
to avoid impacting user-specified & persisted margins.
Differential Revision: https://phabricator.services.mozilla.com/D152900
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
Actually, there's not so much we can improve right now, in the sense
that:
* We need the ::-moz-page-content pseudo-element to be able to set
`display` on the page, since that's a style rule rather than a @page
rule. We could get away without it.
* Keeping the current code-path (slightly cleaned up) is less code, for
now at least. We can have a separate code-path or what not that
actually performs the @page rule selector-matching and what not if
needed when we get to named pages or other page selectors. Selectors
like :first should be pretty trivial to implement, actually.
We make some paged mode anon boxes non-inheriting anon boxes. This
allows us to share the styles and is generally nicer. They don't need to
inherit from anywhere.
We could remove the origin handling and don't look at UA rules or what
not, but it seems pretty harmless to do that.
We also fix the name of the pseudo-elements to match the capitalization.
Differential Revision: https://phabricator.services.mozilla.com/D104772
Without this patch, the rest of this bug's patch-stack can end up improperly
clipping content at the bottom of pages, when printing in 2- and
6-pages-per-sheet configurations.
This clipping problem happens because we build the nsPageFrame's display items
*without direct knowledge* of the fact that it's scaled down, and that ends up
confusing the display list code about whether content is visible. Here's what
happens, when we improperly clip (in a build with all of this bug's patches
except for this one):
(1) We size & scale the print-preview scrollport to display a
landscape-oriented sheet (onto which we plan to lay out two
portrait-oriented pages, if we're e.g. rendering with 2 pages-per-sheet).
(2) The scrollport area gets passed down as the visible area in our
BuildDisplayList codepath.
(3) When we build the display list for a nsPageFrame (before we've applied its
pages-per-sheet scale-down transform), the display list code correctly judges
that some of the page's display items (e.g. its footers) are beyond the bottom
of the scrollport and can safely be clipped. (At first, they seem like they're
beyond the bottom of the scrollport, since they're part of a tall-and-skinny
portrait-oriented nsPageFrame that we're laying out in a scrollport that's been
sized for a short-and-wide landscape-oriented sheet).
(4) Then we scale down the rendered nsPageFrame to place it on our sheet, and
we find that part of the page is missing -- the part that was out of the
scrollport from the display list code's perspective -- even though it's now
transformed to be fully visible.
The simplest fix for this is to temporarily override the visible rect to be the
nsPageFrame's full mRect. This fix prevents us from thinking that any of the
nsPageFrame should be clipped (except for parts that legitimately overflow the
nsPageFrame, which of course are still appropriate to clip).
Note that nsPageFrame itself does this same visible-rect-replacement trick,
when it renders its own nsPageContentFrame child. This patch is partially
cribbed from nsPageFrame's similar code.
Differential Revision: https://phabricator.services.mozilla.com/D100425
This patch doesn't change behavior. It's just a simplification of the data
that we track for our different pages-per-sheet mode (with some minor
refactoring of the logic involved).
This is a necessary step towards implementing support for 2 and 6
pages-per-sheet (which are referenced in comments included in this patch,
and which will be implemented separately in bug 1669905)
Differential Revision: https://phabricator.services.mozilla.com/D99180
... which is an array of pairs of ranges, and use it instead of the
existing printRange / startPage / endPage settings.
Differential Revision: https://phabricator.services.mozilla.com/D96093
The idea here is that we reflow each page as if it were the only page on its
sheet, and then we transform it as-needed to put it in the right
"pages-per-sheet" cell, at paint time.
LIMITATION: Right now I haven't implemented the values "2" and "6", since those
will involve a bit of extra complexity to rotate the sheet to be orthogonal to
the page sizes (and to only do that if the page's aspect ratio merits it). That
will be covered in followup bug 1669905.
Differential Revision: https://phabricator.services.mozilla.com/D86800
This patch does the following things:
(1) It removes the legacy page-range-handling function
"DetermineWhetherToPrintPage()", and it now will always print every
PrintedSheetFrame.
(2) It activates PrintedSheetFrame's page-range handling function so that it
can take over responsibility for skipping pages during print operations.
(3) It adjusts the nsPrintJob code that kicks off individual asynchronous
"print the next page" operations (which is now really "print the next
PrintedSheetFrame). This nsPrintJob code used to have page-range-related
handling interwoven into it, and that handling isn't necessary anymore now that
we're handling page-skipping up front at layout time.
(4) It replaces the mPageNum member-var (which tracks which page we're about to
print or are currently printing) with mCurrentSheetIdx, which is now a 0-based
index into the list of PrintedSheetFrame instances.
(5) It removes nsPrintData:mNumPagesPrinted, which was only used for
progress-bar-completion updates & which basically tracked the same information
that I'm tracking in the new mCurrentSheetIdx variable.
There's some additional cleanup that we should do after this lands (e.g. some
s/page/sheet/ renamings) but I'm holding off on that for now, to keep this
patch relatively targeted.
Differential Revision: https://phabricator.services.mozilla.com/D92660
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.
Differential Revision: https://phabricator.services.mozilla.com/D92696
Per the comment in the patch: if we're given a bogus range, we can technically
end up with a single PrintedSheetFrame that contains no displayable
pages. Luckily, that's a situation that the frontend should detect & recover
from quickly & gracefully, so it's not really a problem. So: in that scenario,
we'll now spam a non-fatal warning; and we'll fatally assert if any sheet
*beyond* the first page has zero displayable pages. (That still shouldn't be
possible.)
Differential Revision: https://phabricator.services.mozilla.com/D89537
For now, we *only* use this new page-skipping code during print preview, via a
PresContext::IsScreen() check. There's a separate legacy codepath that we'll
continue to use for skipping pages during actual printing; see e.g.
nsPageSequenceFrame::DetermineWhetherToPrintPage(). I intend to replace that
codepath soon, but for now I'm leaving it intact, in the interests of making
this patch minimally invasive & low-risk for beta uplift.
Differential Revision: https://phabricator.services.mozilla.com/D87394
This patch shouldn't change behavior at all.
Since our print reflow pipeline doesn't try to handle incremental reflow (per
the early return in nsPageSequenceFrame::Reflow), we can safely assume that our
page frames don't have a preexisting next-in-flow (until we explicitly create
one for them).
This simplifies the logic & the number of scenarios that we need to consider.
Differential Revision: https://phabricator.services.mozilla.com/D88470
Eugeniusz Lewandowski