RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v4]
Phil Race
prr at openjdk.org
Thu Sep 4 22:15:12 UTC 2025
On Thu, 4 Sep 2025 17:39:19 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:
> This is the expected behavior, the same as on other OS. I checked the GraphicsConfiguration on Windows 11, Ubuntu 22.04 and macOS 10.15 with DPI 300 and A4 format. The device boundaries on macOS are 1 pixel different. The console output is below.
>
> **Windows 11**
>
> ```
> Page format size: 595.275574 x 841.889771
> Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507]
> Run: 1, Page index: 0
> java.lang.Throwable
> at DevConfig$DevicePrintable.print(DevConfig.java:38)
> at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2212)
> at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1601)
> at DevConfig.main(DevConfig.java:23)
>
> Page format size: 595.275574 x 841.889771
> Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507]
> Run: 2, Page index: 0
> java.lang.Throwable
> at DevConfig$DevicePrintable.print(DevConfig.java:38)
> at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2252)
> at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1601)
> at DevConfig.main(DevConfig.java:23)
> ```
>
> **Ubunut 22.04**
>
> ```
> Page format size: 595,275574 x 841,889771
> Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507]
> Run: 1, Page index: 0
> java.lang.Throwable
> at DevConfig$DevicePrintable.print(DevConfig.java:41)
> at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2243)
> at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1632)
> at DevConfig.main(DevConfig.java:25)
>
> Page format size: 595,275574 x 841,889771
> Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507]
> Run: 2, Page index: 0
> java.lang.Throwable
> at DevConfig$DevicePrintable.print(DevConfig.java:41)
> at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2283)
> at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1632)
> at DevConfig.main(DevConfig.java:25)
> ```
>
> **macOS 10.15**
>
> ```
> Page format size: 595.275567 x 841.889771
> Device bounds: java.awt.Rectangle[x=0,y=0,width=2479,height=3508]
> Run: 1, Page index: 0
> java.lang.Throwable
> at DevConfig$DevicePrintable.print(DevConfig.java:36)
> at java.desktop/sun.lwawt.macosx.CPrinterJob$4.run(CPrinterJob.java:919)
> at java.desktop/sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(CPrinterJob.java:938)
> at java.desktop/sun.lwawt.macosx.CPrinterJob.printLoop(Native Method)
> at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:383)
> at DevConfig.main(DevConfig.java:21)
>
> Page format size: 595.275567 x 841.889771
> Device bounds: java.awt.Rectangle[x=0,y=0,width=2479,height=3508]
> run: 2, Page index: 0
> java.lang.Throwable
> at DevConfig$DevicePrintable.print(DevConfig.java:36)
> at java.desktop/sun.lwawt.macosx.CPrinterJob$2.run(CPrinterJob.java:838)
> at java.desktop/sun.lwawt.macosx.CPrinterJob.printToPathGraphics(CPrinterJob.java:852)
> at java.desktop/sun.lwawt.macosx.CPrinterJob.printLoop(Native Method)
> at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:383)
> at DevConfig.main(DevConfig.java:21)
> ```
Yes it is. I realized that afterwards but didn't get round to updating my comment.
>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 904:
>>
>>> 902: new BufferedImage(
>>> 903: (int)Math.round(scaledPageFormat.getWidth()),
>>> 904: (int)Math.round(scaledPageFormat.getHeight()),
>>
>> Wow, that is going to be one big BufferedImage. This doesn't seem right or necessary for a PeekGraphics.
>>
>> Look at RasterPrinterGraphics. It uses a 1x1 image (!) It just sets things up so that when the app asks for the graphics config it gets the page dimensions back.
>
> This is a good point, but I have not changed the existing approach to creating a PeekGraphics. A BufferedImage is created based on the paper format size and DPI.
> Does changing the approach to memory consumption align with the goals of this PR, to be able to set the document's DPI to match the printer's DPI?
supposing we have a 1200 dpi printer and someone prints to A3 paper.
That's approx 12x16 inches and its ARGB so
12 * 1_200 * 16 * 1_200 * 4 .. that's over a Gigabyte !
So what you are doing isn't viable as well as unnecessary.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2323153257
PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2323166219
More information about the client-libs-dev
mailing list