问题
We have a problem using Paperclips (printing library for SWT) on scaled monitors, but I don't think it has anything to do with the framework and all with the Eclipse environment.
Let's see an example:
Left is the print with no scaling (or 100%), right is the same print started on a monitor with 175% scaling. I know what you are thinking: the monitor and its resolution / scaling should have no influence on a print. Right, should.
While that's sad and all, it would not be much of a problem. But there comes the kicker: The above prints were generated by a JUnit test case run as plug-in test. If I run them as a regular unit test both work.
Clearly something in the Eclipse environment works differently when started in an OSGi context, and I'm trying to find out what it is (so I can maybe prevent it).
And I think that's a nice puzzle.
If you need a hint for what SWT class might be the , I narrowed it down to this file ScalePrint.java for the table (i.e if I remove the instance of ScalePrint from my demo, the table is displayed correctly; the header is still wrong, though).
I can confirm the error exists only in Eclipse 4.6, and not 4.5 or 3.7 (which is not entirely surprising, since 4.6 is the first version to support scaling). And if I add -Dswt.autoScale=100 to the VM options to disable scaling, it works as expected, too.
I could append my test case, but as I said, I don't really think it has anything to do with Paperclips per se.
So... what could break the scaling when the entire Eclipse framework is started compared to running the same code in a plain Java application?
回答1:
The Problem is the use of the class Transform, which itself uses the static field DPIUtil.deviceZoom (in the form of DPIUtil.autoScaleUp(float dx)).
Since DPIUtil.deviceZoom is a static field everything fails when used with a primary monitor that has scaling (since printers don't).
来源：https://stackoverflow.com/questions/46660031/scaling-handled-differently-in-java-and-eclipse-framework