TextLayout is fine as it is.
If it aint broken, dont need fix.
To unsubscribe, send email to firstname.lastname@example.org and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
email@example.com and include in the body of the message "help".
Gregory Pierce wrote:
> ---------------------- Information from the mail header -----------------------
> Sender: Discussion list for Java 2D API
> Poster: Gregory Pierce
> Subject: Why does TextLayout operate different from the rest of Java2D?
> I've been messing around with TextLayout for a while now and have
> become increasingly annoyed with the semantics of TextLayout in that
> it doesn't operate like the rest of the stuff in Java2D.
> Graphics2D has the ability to draw everything else I've thrown at it
> except a TextLayout. TextLayout for some reason that just escapes me
> lives in its own coordinate space and must be translated into place in
> order to be drawn.
What? The draw(Graphics2D g, float x, float y) API can draw the text
layout at any x,y location in the graphics. There's no API on
Graphics2D to draw it, but nothing requires you to translate the graphics.
Then you have to translate back to where you were
> so you don't screw up the rest of your drawings. My code is full of
> stuff like
> g2d.translate( textX, textY );
> textA.draw( g2d, 0, 0 );
> bounds = textA.getBounds();
> g2d.translate( -textX, - textY );
> g2d.setColor( textBFontColor );
> // compute textBX, textBY
> g2d.translate( textBX, textBY );
> textB.draw( g2d, 0, 0 );
> g2d.translate( -textBX, -textBY );
> Seems to be a lot of work as opposed to:
> g2d.draw( textA, textX, textY );
> g2d.setColor( textBFontColor );
> g2d.draw( textB, textBX, textBY );
Or, for that matter, this:
textA.draw(g2d, textX, textY);
textB.draw(g2d, textBX, textBY);
> Maybe I'm missing the reason for having TextLayout live off on its
> own. The problem becomes more compounded when you want to do hit
> testing on characters or draw the carets that would result from the
> hit test. Am I missing something, or is this a piece of API that needs
> to be 'updated' to be more in line with the rest of Graphics2D.
1) The semantics of existing API will not be changed. We angered enough
people when we changed the behavior of getGlyphVisualBounds to make it
consistent. This is a stability issue.
2) TextLayout is immutable. You can't, for example, set its position
and then ask for the position later. Whether this was a good idea is
debatable, but it's part of the current design. As code may rely upon
this (e.g. it passes TextLayout into another API, and assumes the
TextLayout comes back unchanged) this will not change.
3) TextLayout is a complex object, and has (potentially, at any rate) a
lot of state. Java2D does not consider it a 'primitive object', whereas
it does consider String and GlyphVector, for example, to be primitive
objects. The decision was made in 1.2 to provide the TextLayout API,
but not provide API on Graphics2D for rendering TextLayout. It's
debatable, but overall doesn't seem to make a difference in terms of
I think we'll have to live with TextLayout's current design. You can
wrap a TextLayout in an object that stores its position and translates
between these coordiantes and TextLayout's internal coordinates. It's
not as good as not having to write the wrapper at all, but it can handle
your coordinate conversion issues.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.