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

[eduardsdv]

On Tue, 18 Nov 2025 15:01:14 GMT, Christian Heilmann <duke at openjdk.org> 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