On Tue, 18 Nov 2025 15:01:14 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 incrementally with three > additional commits since the last revision: > > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m > Let me add links to the Apple documentation. > ... > I assume that "knowsPageRange" is the size of the whole document, and that printingDictionary's NSPrintFirstPage and NSPrintLastPage is the printing range of the document the user selected. Thanks for the links, @GennadiyKrivoshein. Yes, I also understand macOS to work this way. It seems that the ``knowsPageRange()`` is required, while ``NSPrintFirstPage`` and ``NSPrintLastPage`` are optional. These are also used to pre-fill the print dialog. I would also like to respond to your comment, @aivanov-jdk. > Phil said and you agreed that the page range was applied twice. Do I > understand it correctly? Yes > Previously, we passed the correct range of pages to macOS via > knowsPageRanges(), for example 2β4. No, I wouldn't say this is correct; it's what caused the bug. However, macOS also handles this data by printing only the pages in the range 2stβ4st. > The proposed fix changes the code so that the range is pages isn't passed to > macOS, or rather page 1 to number of pages. Yes, the ``knowsPageRanges()`` is used to inform the macOS about the number of available pages by returning a range 1-N. > Then when printing Java applies the requested page range. > Is it possible to pass the known page range to macOS and was done before the > current PR? For example, to print pages 2β4, pass the start page 2 and the > number of pages 3. (The number of pages to print is known even if a Printable > interface doesn't return the number of pages.) > Then modify the printing code in Java so that it doesn't apply the page range > again, but just prints the requested pages instead. After spending some time thinking about it, I would say, it would be possible to use only the ``knowsPageRanges()`` function to print a sub-range of available pages. I also tested it. It works indeed, when **no print dialog** is used. When a program uses the native macOS print dialog, or even a custom one, it needs to pass the **total number** of pages and optionally the **suggestion/pre-fill** via the ``PageRanges`` parameter. So there are two pieces of information that we need to pass to macOS. Combining them into one range returned by the ``knowsPageRanges()`` function would be difficult, if not impossible. I'm asking why we should do that when macOS offers two APIs for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3569782352
