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
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 is to make GetDPIRatioForScrollbarPart thread-safe for stylo usage.
This was using the widget for bug 1727289, but just looking at the print
preview scale is enough to fix that.
Reviewed in: https://phabricator.services.mozilla.com/D168148
For that we need to:
* Make GetDPIRatioForScrollbarPart thread-safe: This was using the
widget for bug 1727289, but just looking at the print preview scale
is enough to fix that.
* Make nsPresContext::UseOverlayScrollbars() thread-safe: We store the
RDM pane stuff in the pres context.
The rest is pretty straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D168148
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
nsPageSequenceFrame does a thing where it grows its desired size to fit the
AvailableISize and ComputedBSize (under the assumption that those are the
actual dimensions of our scrollport, which it wants to make maximal use of).
This behavior causes trouble when it's reflowed under the privileged
'sizeToContent' JS API. That API makes us reflow with nscoord_MAX as the
viewport's ComputedBSize(), and this nscoord_MAX value gets passed down to be
the nsPageSequenceFrame's ComputedBSize as well. When we reach the code in
question, we dutifully grow the desired size to that bogus huge value, which is
clearly wrong.
This patch addresses this issue by simply declining to grow the desired size in
the scenario where ComputedBSize() is unconstrained. This leaves us with
reasonable values for our desired size (which are actually based on the
content, which makes it the right thing to do for the purpose of a
SizeToContent() call).
Differential Revision: https://phabricator.services.mozilla.com/D135762
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
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
This code currently does a recursive tree-traversal to get a list of all canvas
elements that might be used for PDF.js content, so that we can invoke the
appropriate callbacks on them to let PDF.js prepare for printing.
In this patch, I'm adjusting the outermost level of that traversal to make it
aware of the fact that PrintedSheetFrames may now contain many skipped
nsPageFrames whose content we don't want to render.
Depends on D101941
Differential Revision: https://phabricator.services.mozilla.com/D101942
This patch doesn't change behavior; it just adds a static_cast to a
more-specific type that we know the variable has, and updates the signature and
callsites.
(The next patch will make use of the fact that we know this type.)
Differential Revision: https://phabricator.services.mozilla.com/D101941
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
This renames kTimeFormatSeconds to kTimeFormatLong and kTimeFormatNoSeconds to
kTimeFormatShort. This is consistent with the naming used for date format
selectors.
Differential Revision: https://phabricator.services.mozilla.com/D93011
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 code looked like it might work, but it seems to have only ever been backed
by per-printer about:config prefs. I believe we only ever exposed UI for this
feature on Linux, via the native GTK dialog; and even there, the UI doesn't
actually seem to have done anything -- it was never wired up to the actual
implementation of even/odd page-skipping.
Differential Revision: https://phabricator.services.mozilla.com/D92528
We were adding the unwriteable to the default margin. I was going to
consider not painting the headers / footers if they overlapped with the
content box of the page, but turns out our default configuration
overlaps slightly at the bottom, so I just punted on that.
Users can remove the headers / footers quite easily anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D89794
