On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann <[email protected]> wrote:
>> This PR fixes a bug that caused no or the wrong set of pages to be printed >> when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from >> the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request with a new target base due to > a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains five additional > commits since the last revision: > > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 > - Merge branch 'master' into pr/11266 > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > 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? 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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3547984684
