<Swing Dev> [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text

[Philip Race]

This seems to invalidate the preceding comment as well as contradict 
it's intent :

/* The printed text must scale linearly with the UI.
  519                  * Calculate the width on screen, obtain a TextLayout with
  520                  * advances for the printer graphics FRC, and then justify
  521                  * it to fit in the screen width. This distributes the spacing
  522                  * more evenly than directly laying out to the screen advances.
  523                  */


I am not sure when
  531                     if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) {
would return "false" since we are in an isPrinting() block and you
are comparing the screen and printer FRCs, so then you will inevitably end up calling
  532                         layout = createTextLayout(c, text, g2d.getFont(), frc);

which will create spacing at screen resolution.

In the other two places in this file where a test similar to that at 531 
is used,
if the result is that they aren't compatible, then a TextLayout is created
using the deviceFRC .. the opposite of what you are doing here.

So I think you will regress https://bugs.openjdk.java.net/browse/JDK-6488219

Are you running Swing printing tests when you make changes here ?

The bug above is covered by java/awt/print/PrinterJob/SwingUIText.java
but it is manual since pass/fail is a subjective manual verification ..

-phil.

On 1/25/19, 3:41 AM, Prasanta Sadhukhan wrote:
>
> Hi All,
>
> Please find an updated webrev using FontRenderContext compatible to 
> printer device. With this, swing text with and without leading spaces 
> are printed ok.
> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.1/
>
> Regards
> Prasanta
> On 25-Jan-19 11:01 AM, Prasanta Sadhukhan wrote:
>>
>>
>>
>> On 25-Jan-19 10:57 AM, Philip Race wrote:
>>>
>>>
>>> On 1/24/19, 8:19 PM, Prasanta Sadhukhan wrote:
>>>>
>>>>
>>>>
>>>> On 25-Jan-19 2:00 AM, Phil Race wrote:
>>>>> I can't work out what you are trying to say.
>>>>> The changes are only in the printing code path.
>>>>>
>>>>> However what it looks like to me is that Prasanta is now using 
>>>>> TextLayout for printing only under
>>>>> the same conditions as we use it on screen -- which is when 
>>>>> "international" text is being rendered.
>>>>> This will reintroduce clipped text bugs which the existing code 
>>>>> was meant to fix so I don't think it
>>>>> can be right.
>>>> OK. Thanks for the info. I didn't know that as I am not able to get 
>>>> the fix for JDK-6760148 which is pre 7u23 where mercurial tracking 
>>>> began.
>>>>>
>>>>> It may not be pretty or a complete solution but I think we need to 
>>>>> look at breaking the text into
>>>>> the leading spaces + the rest of the trimmed string and using the 
>>>>> screen advance of the
>>>>> leading spaces to position the rest of the justified text.
>>>> Are you implying the leading spaces in text is making text 
>>>> justifcation going astray?
>>>
>>> Yes.
>>>
>>>> I have seen even without leading spaces in swing text in console
>>>>
>>>> , the text justification during printing is wrong as I am getting
>>>>
>>>>
>>> That is quite different from what you showed earlier.
>> The earlier embedded image was "with" leading spaces inswing text. 
>> The above was "without"
>>
>> Regards
>> Prasanta
>>> The first visible chars are all aligned properly. But all the 
>>> adjustment for the width
>>> is being assigned to one space.
>>> For this you will need to look into the text layout justification code.
>>>
>>> -phil.
>>>
>>>> Regards
>>>> Prasanta
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 1/24/19 9:33 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta.
>>>>>>
>>>>>> On 24/01/2019 02:18, Prasanta Sadhukhan wrote:
>>>>>>> Proposed fix is to check if we need text layouting for printing 
>>>>>>> too as it is done for swing text drawing on console. If we need 
>>>>>>> text layouting, then only use textlayout justification.
>>>>>>
>>>>>> For swing components we skip textlayout by default because of 
>>>>>> performance reason(when we know that it should be safe to do), 
>>>>>> are you sure that it is safe in your case? Will the text scales 
>>>>>> in the same way as the components on which it drawn?
>>>>>>
>>>>>> BTW the new codepath missed the call:
>>>>>> g2d.setColor(((PrintColorUIResource)col).getPrintColor());
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190127/7037fe18/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1991 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190127/7037fe18/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 7295 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190127/7037fe18/attachment-0001.png>