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

[Philip Race]

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 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/20190124/6ea2b414/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/20190124/6ea2b414/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/20190124/6ea2b414/attachment-0001.png>