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

[Sergey Bylokhov]

On 24/01/2019 12:30, Phil Race wrote:
> I can't work out what you are trying to say.
> The changes are only in the printing code path.

The Swing components can be printed in the same way as drawn
to the screen. The screen and printer will have different DPI,
the components itself will use drawLine/drawRect/etc,
I am not sure that g2d.drawString() will handle it well, since
screen and printer will have different fontmetricsas(as a result the text can
be drawn outside/on_border of the component)

So I think that the usage of TextLayout.getJustifiedLayout() in this codepath
is unrelated to TextAttribute.NUMERIC_SHAPING.


> 
> 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.
> 
> 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.
> 
> -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());
>>
>>
> 


-- 
Best regards, Sergey.