---------------------- Information from the mail header ----------------------- Sender: Discussion list for Java 2D API <[EMAIL PROTECTED]> Poster: Gregory Pierce <[EMAIL PROTECTED]> 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); g2d.setColor(textBFontColor); 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.
Some points:
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 functionality.
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.
Doug
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
