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.
