I removed the unused deviceTransform variable.
http://cr.openjdk.java.net/~prr/8132890.1/
Is there any thing else ?
-phil.
On 10/19/2015 02:29 PM, Philip Race wrote:
On 10/19/15, 5:10 AM, Sergey Bylokhov wrote:
Hi, Phil.
Looks like in this method we have too many things named as deviceXX.
Am I understand correctly that
1) AffineTransform deviceTransform = getTransform(); returns
device+users transformation?
Yes .. and "device" transform is more than just what the device
transform really is.
It also includes the transform necessary to have user space start off
as landscape,
reverse landscape, or reverse portrait.
2) fontTransform contains full transform dev+user+font?
Yes, all of (1) plus what ever transform is on the font.
And in the fix we remove trueDeviceTransform from the fontTransform,
to calculate advance? I wonder how many steps we do for that.
Well .. it is about a dozen lines of code but is that what you are
really asking ?
There should not be any performance issue here. The printing path has
many
operations that take orders of magnitude more time.
One small cleanup is possible also, the deviceTransform is not used
anymore after the fix in textOut();
Ah .. I will remove it.
-phil.
On 17.10.15 2:16, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8132890
http://cr.openjdk.java.net/~prr/8132890/
The notable thing about this case is that the printer has different dpi
in x and y.
In GDI printing we detect when the transform under which the font is
rendered is non-uniform as in that case we want to tell GDI to create
a stretched font as that is better than trying to draw the text as a
filled path.
What happens here is that the *device resolution* is not uniform.
It is a scale of (3.33, 2.0) - ie 240x144 dpi so x=1.66*y
This device resolution then gets combined with any graphics transform
and the font transform and we have lost sight of the fact that the
non-uniform part came from the device rather than the application
specifying an additional x-scale factor to be applied.
GDI is already accounting for the real device resolution and we cause
it to be applied twice.
So we need to divide this out as part of the calculation.
This needs access to the real device dpi to be passed in/made
available.
But there is another issue. JDK puts the printer job into portrait
mode
even in landscape printing and takes care of the transforms itself.
So the size used to set the font for GDI needs to use GDI's idea of the
orientation.
I augmented a text printing test used to verify this with some
additional scenarios.
It is now a pretty comprehensive test of many different scenarios.
It has been tested on an HP LaserJet, the Oki dot matrix printer and
the
XPS driver.
There is also a not completely necessary tweak here to adjust the
error we
allow in gdi vs jdk advances from 0.2% to 1%. This made for about a 25%
reduction in the overall spool file size for my test with no noticeable
consequences.
-phil.
