[OpenJDK 2D-Dev] RFR: 8132890 Text overlapping on dot matrix printers.

Philip Race philip.race at oracle.com
Mon Oct 19 21:29:10 UTC 2015



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.
>>
>
>



More information about the 2d-dev mailing list