On Tue, 18 Nov 2025 16:36:40 GMT, Alexey Ivanov <[email protected]> wrote:
> Will Java code still handle this situation correctly if the OS decides to > print in reverse order? If the number of pages is not known, I can imagine two strategies how the macOS can handle this: 1: The macOS starts with the first page, iterates over all pages, stores them all in a cache and only then sends them to the printer in reverse order. In this case, the pages are acquired from the Java program in the usual order. 2: The macOS iterates through all the pages, starting with the first and working towards the last. It then knows how many pages there are and can access them in reverse order. In my opinion, it should work either way because the Java printing API supports random access order. >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? The intention to print only a range of pages is communicated to macOS via the ``CPrinterJob.javaPrinterJobToNSPrintInfo()``. The ``PrinterView.knowsPageRanges()`` is used to return the full range of available pages (or the range of pages that program can print) and therefore it must always return the range [1..``Pageable.getNumberOfPages()``]. > 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”? The PR fixes precisely this problem, whereby the page range passed via ``PageRange`` was forwarded twice to macOS. One time in ``PrinterView.knowsPageRanges()`` and the second time in ``CPrinterJob.javaPrinterJobToNSPrintInfo()``, which led to the setting of "a range withing range". Now, only the ``CPrinterJob.javaPrinterJobToNSPrintInfo()`` is responsible for passing of ``PageRange`` to macOS. The ``PrinterView.knowsPageRanges()`` just returns the number of available pages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3553611629
