JDK-8165335 : Clarify handing of PageRanges, possibly with new API.
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-09-02
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Description
This bug report is mainly a place to document the implication of PageRanges,
whether set by the app. or the user in the print dialog.

We may at some point make some updates to improve matters but not for JDK9.

When PageRanges are in effect the underlying print job (let's call it the ImplJob)
that implements the JavaFX PrinterJob is ideally expecting to print exactly the
number of pages implied by the PageRanges. It may terminate before then,
but trying to print more will not work because the ImplJob has implicitly completed.
So when ask for pages 1..N and try to print page N+1 you get job status set to ERROR.
No more pages will be printed - they can't be as ImplJob is done.

A robust application should be checking for ERROR and know there is no point
in continuing. It should also know that if PageRanges is exceeded that would be
the reason for the ERROR. Perhaps we can do something to make it a little easier
but for the most part the information needed is available if you know where to look.
The catch would be if you don't know how many pages have actually been sent so
far, so you don't know it has been reached.
The WebEngine.print(PrinterJob) API does not do anything to tell you how many
pages were printed .. in fact it just returns void. Nor does it provide any way
for you to explicitly control which pages are printed.

This leads us to the second general observation.

There are two basic models of how PageRanges should affect a say 20 page document
you want to print, where the user asks for just pages 5-10.
1) The application images all 20 pages and ImplJob "drops" all but the requested pages.
This means that even if the application needed to layout up to Page 10 to print,
it then spends a load of time on pages 11-20 that go nowhere ..

2) The application uses the PageRange setting to image just the pages requested by
the user. The application knows to skip pages 1-4 and then image pages 5-10 and
then stop. This is the model in use in FX. It is also how Windows printing works.

So this means it is up to the application to pay attention to PageRanges.

So if an application creates a PrinterJob with intent to print some WebView content
and the user sets PageRanges to 1-2, they really don't *know* if there are even two
pages of content unless Webview provided an API to let you know this.

But let us suppose that the web content will be 5 printed pages, and that WebEngine
is fixed to honour the PageRanges .. it will then print just pages 1-2.
Fine for most cases.

But if the application had wanted to print this content either preceded or
followed by some other content, then webengine has no way of knowing that.
It follows that in the event the application wants to do this it needs to make sure
that PageRanges are removed before initiating printing .. but now there is no
way to constrain WebEngine to just a subset of its pages.
So we may need some new API around this but it needs more thought.