[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR: 8132890 Text overlapping on dot matrix printers.
From:       Sergey Bylokhov <Sergey.Bylokhov () oracle ! com>
Date:       2015-10-21 13:37:51
Message-ID: 5627952F.30901 () oracle ! com
[Download RAW message or body]

On 21.10.15 2:13, Phil Race wrote:
> I removed the unused deviceTransform variable.
> http://cr.openjdk.java.net/~prr/8132890.1/
>
> Is there any thing else ?

No, Fix looks fine.

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


-- 
Best regards, Sergey.
[prev in list] [next in list] [prev in thread] [next in thread]