On 4/9/20, 10:26 PM, Jayathirth D v wrote:
Hi Phil,
I went through all use cases captured in test case (TextLayout, draw).
With updated change there is difference in behaviour between how we
interpret non-invertible transform between TextLayout.draw() and
draw() API’s.
In case of Te
Oh and if you do draw it, it still goes through the GV path so nothing
should draw there.
This is what I meant by :
> Subsequent rendering of the TextLayoutwill be handled by the other
checks being added.
The shape returned might be not be null but I don't think you'll get
more than a line .
Hi Phil,
I see your point of allowing queries on text layout without throwing exceptions.
I was also under the impression that we should not see text getting drawn when
we try to draw it using TextLayout with your change.
For more clarification I am adding what I tested :
I used code from your
Could you describe here the ideas behind your fix and what the
implications are
1) I'm sure I've seen printers that describe the same paper size by
multiple names.
Why is it a problem here ? If it is because we have the same display
name, is that
just for known standard sizes ? Can we get the
You're right.
This is because I did not apply the non-invertible transform on the
graphics and do
what would be more normal which is to call
Graphics2D.getFontRenderContext() to
create the TextLayout so that it matched. The constructor FRC is for
layout not rendering.
So in other words unless t
You're right.
This is because I did not apply the non-invertible transform on the
graphics and do
what would be more normal which is to call
Graphics2D.getFontRenderContext() to
create the TextLayout so that it matched. The constructor FRC is for
layout not rendering.
So in other words unless t
Sorry for the resend - my mailer claimed it had failed !
-phil.
