Hi Phil,
I assume you've run all the manual regression tests on text? The
copyright year in the regression test needs updating. Otherwise, looks
good.
Jennifer
On 10/16/2015 04:16 PM, 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.
