On Tue, 18 Nov 2025 14:53:00 GMT, eduardsdv <[email protected]> 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
