RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2]

[Alexey Ivanov]

On Tue, 18 Nov 2025 14:53:00 GMT, eduardsdv <duke at openjdk.org> wrote:

> > I am still for simplifying the code if we're accepting what's currently suggested:
> > 
> > 1. Get rid of `totalPages`.
> > 2. Always use NSIntegerMax and remove the fTotalPages field.
> 
> The operating system may choose a different printing strategy (for example printing in reverse order) or UI feature depending on whether or not it knows the total number of available pages. If we know the number, why hide this information?

You're right…

Will Java code still handle this situation correctly if the OS decides to print in reverse order?

> Furthermore, even if macOS's current behaviour does not differ essentially (see this [comment](https://github.com/openjdk/jdk/pull/11266#issuecomment-3496509402)), it may do so in the future. Do we really want to touch this code again in the future?

Fair enough. I agree it should be future-proof.

On the other hand, as Phil highlighted, should we then communicate our intent of printing the range of pages to macOS and pass *the start page* correctly as we do now (in the unfixed code) contrasting with always passing 1 in the suggested fix? And, instead, to modify the code that applies the range for the second time to ensure “we are **NOT** setting a range within a range”?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3548524383