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