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

[Phil Race]

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