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

Prasanta Sadhukhan prasanta.sadhukhan at oracle.com
Mon Jan 28 04:37:20 UTC 2019 


On 28-Jan-19 12:23 AM, Philip Race wrote:
> 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.
In drawStringImpl(), I guess it is doing the same as I am doing (calling 
with screen frc if not compatible)
if (isPrinting) {
                 FontRenderContext deviceFRC = g2d.getFontRenderContext();
                if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) {
                     layout = new TextLayout(iterator, deviceFRC);
                     AttributedCharacterIterator trimmedIt =
getTrimmedTrailingSpacesIterator(iterator);
                     if (trimmedIt != null) {
                         float screenWidth = new TextLayout(trimmedIt, frc).

I am not sure if the comment in l519-523 is introduced in JDK-6488219
(as I am not able to see the fix in JBS)
but since it is claimed that this bug is regression from this fix 
onwards, maybe this comment is not sacrosanct.

>
> 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 ..
>
I ran with / without fix and this looks the same to me. Attached are the 
output.

Regards
Prasanta
> -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/20190128/af98af6d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oiaeipaohanmijgk.png
Type: image/png
Size: 1991 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190128/af98af6d/oiaeipaohanmijgk-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fjceobdokjhnelnb.png
Type: image/png
Size: 7295 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190128/af98af6d/fjceobdokjhnelnb-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print-output-beforefix.pdf
Type: application/pdf
Size: 465555 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190128/af98af6d/print-output-beforefix-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print-output-afterfix.pdf
Type: application/pdf
Size: 465555 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190128/af98af6d/print-output-afterfix-0001.pdf>

More information about the swing-dev mailing list