[arch] TextPainter API opinions

[Bill Haneman <Bi...@ireland.sun.com>]

Hi:

Now that the GraphicsNodeRenderContext
(and thus the TextPainter) is available to 
TextNode.getBounds(), getPrimitiveBounds(),
getGeometryBounds(), etc., I can remove the hacks
that are currently enabling text bounds support.

I propose an inner class of TextPainter that
is similar to TextLayout in function, and am very
comfortable with this part of the architecture
(TextPainter.TextLayout would first proxy a 
java.awt.font.TextLayout, which is jsut a refactoring
of what we have now.  Then we could create our
own extended implementation that matches java.awt.font.TextLayout,
using Font and GlyphVector, and slot it in when ready).

There are a couple of minor questions about how the
API would look that I am looking for opinions about.
If you have no strong opinion that's fine, I don't
think it's going to matter functionally, only in the
API signatures.

Here they are:

1)  To get the bounds for a TextNode from a TextPainter,
    do you prefer
    
1a. textPainter.getTextLayout().getBounds2D(
                                    boolean includeDecoration,
                                    boolean includeStroke);

1b. textPainter.getBounds2D(boolean includeDecoration, 
                            boolean includeStroke);
                            
PROS/CONS:

1b is simpler and means that the TextPainter.TextLayout inner
   class need not be exposed [and we could build alternative
   TextPainters that don't use TextPainter.TextLayout];
   
1a means that users of TextPainter have access to all of
   TextPainter.TextLayout without needing to add more than
   one property to TextPainter (2 methods, get/setTextLayoutFactory).
   
Also if we went with 1b, the inner class could be in refimpl
and not in gvt.
   
2)  We have, up until now, used AttributedCharacterIterator plus
   Anchor and Location as TextPainter parameters
   (for instance, in TextPainter.paint(...).
   
   Should we:
   
   
2a   continue to use this pattern in TextPainter.getBounds2D()
   (if we use 1b) or TextPainter.TextLayout.getBounds2D()
   
2b   convert to using a one-parameter signature:

    TextPainter.paint(TextNode node);

    TextPainter.getBounds2D(TextNode node);
    
    [or TextPainter.getTextLayout().getBounds2D(TextNode node)]
  
PROS/CONS:

Little difference, except that 2b would allow for TextNode to
be converted to composite with TextPath children, etc. if that
were advantageous.  Note that implementation of TextPath doesn't
require this, it could be done via a TEXT_PATH attribute on the
ACI instead.
    
I think that I prefer #1b and #2b, but could live with
any of these options.

If you can think of significant advantages/disadvantages to
these options, please speak up!  I'd like to code one of
the options tomorrow or Wednesday before the holidays,
so I can work on an alternate implementation away from CVS 
access.

Thanks,

-Bill



------
Bill Haneman +353 1 8199279
Ireland Desktop Engineering
Sun Microsystems Ireland Ltd.

Re: [arch] TextPainter API opinions

[Thierry Kormann <Th...@sophia.inria.fr>]

Bill,

Sorry for the delay but I had many things to do yesterday... A longer
email/proposal-for-conwork should come today but here are quick answers.


> 1)  To get the bounds for a TextNode from a TextPainter,
>     do you prefer
> 
> 1a. textPainter.getTextLayout().getBounds2D(
>                                     boolean includeDecoration,
>                                     boolean includeStroke);
> 
> 1b. textPainter.getBounds2D(boolean includeDecoration,
>                             boolean includeStroke);

I think 1b is better

I don't really like the two booleans. May 3 getBounds methods
like GraphicsNode could be better? Otherwise, it's not a problem for me.

> Also if we went with 1b, the inner class could be in refimpl
> and not in gvt.

I plan to ask to remove all refimpl packages!


>     TextPainter.getBounds2D(TextNode node);

I really prefer than one at the moment.
The good point is that we are going to have something similar than the 
ShapePainter API.


See you later,
Thierry.

-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr 
http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis