RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out

Phil Race prr at openjdk.org
Fri Jul 11 18:22:47 UTC 2025


On Thu, 10 Jul 2025 21:47:09 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> To achieve good image printing quality, the printed image must be drawn using the printer's DPI or close to it if the DPI isn't known. The page is rendered in the following sequence "User Image" -> CPrinterGraphics -> SunGraphics2D -> CPrinterSurfaceData -> OSXSurfaceData -> "Native macOS User space".
> 
> CPrinterSurfaceData, OSXSurfaceData, and "Native macOS User space" from the rendering sequence are tightly coupled and contain data that is used in both native code and java, as well as CPrinterSurfaceData and OSXSurfaceData reflect the user space provided by macOS for rendering, including size and DPI, which is convenient and expected, and all the work on translations from the user space to the device space are performed automatically by macOS. Thus, I assumed that it is not reasonable to change anything in CPrinterSurfaceData and OSXSurfaceData.
> 
> To enable the user to determine the actual DPI of the printer, it remains possible to make changes to CPrinterGraphics or SunGraphics2D. I decided to add changes to SunGraphics2D because it is closer in the chain to rendering in macOS, and it also provides means for setting the necessary parameters through the existing public methods (setDevClip), and perform the reverse translation into the macOS user space in native code using scale methods specifically designed for this purpose. It is possible to add an additional constructor to SunGraphics2D that takes into account the necessary scaling, and thus avoid using setDevClip, but this changes the actual API of SunGraphics2D, which I tried to avoid.

Nothing else in the entire desktop module needs to directly set the device clip in this way.
Why is this case so unique ? 
I think there must be a better way that you've overlooked and it won't involve adding new code to SunGraphics2D

Also as I noted you are NOT using the actual DPI of the printer. You've just decided to use 300 instead of 72
Your hard-coded 300 gets used no matter what the real printer DPI.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2201487078


More information about the client-libs-dev mailing list