Font Metrics (was TextField Document model)

[Richard Bair]

I think these are two distinct issues -- font metrics and locating glyph bounds within a string of text. FontMetrics I think is fairly straightforward -- Felipe what do you think?

For the other use case, actually knowing the glyph bounds is not enough (probably). The problem is, suppose that text you were looking for wrapped from one line to the next (letter wrapping instead of word wrapping, or maybe you were searching for a phrase rather than just a word). In this case you need to know the shape that would encompassing text from both lines (think: blue selection box). Even more challenging is BIDI and ligatures -- what if the text you searched for was only using part of a glyph due to ligatures? Or you have disjoint shape due to BIDI (selection is a good example of this again).

Now, internally we use an impl on Text to get the shape based on a range of indexes into the Text, and this shape is then used to draw selection. In our quest to get rid of impl methods, I have wanted to see this get proper API treatment. Maybe we would have a TextMeasurement class, and Text node (and TextFlow) would return an instance of it and we could have a method on it that vends a shape. Once you have a shape you can set the fill, stroke, etc as you like.

Richard

On Oct 22, 2012, at 8:21 PM, Scott Palmer <swpalmer at gmail.com> wrote:

> While we are talking about the text controls. I would like to request access to either the FontMetrics or a way to accurately position things based on a position in the text without having to implement a Skin.  E.g. an auto-complete popup, or something like what OS X does when you look up a definition of a word.
> 
> Like this:
>      <PastedGraphic-1.tiff>
> (heck, even it got it off by a pixel vertically)
> 
> Or perhaps the may to do this is covered in the goal to make Skins a bit more "public".  I think I read that was a goal somewhere.
> 
> I recently implemented something like an auto-complete popup and to do it well I needed to set the skin on the TextField to my own subclass of TextFieldSkin just to expose the fontMetrics.  It worked out, but I felt dirty doing it :-) and I didn't properly account for various insets etc.
> 
> I'm guessing that a Time/Date field and others would benefit from popups like a calendar, etc.  Maybe this is off-topic and it really should be done by implementing a custom Skin?
> 
> 
> Regards,
> 
> Scott
> 
> 
> 
> 
> On 2012-10-22, at 11:47 AM, Richard Bair <richard.bair at oracle.com> wrote:
> 
>>> Would you consider having a setContent(TextFieldDocument doc) method in
>>> TextField?  The length() method and the get(int, int) method could be
>>> final, making it necessary to call super.insert() or super.delete() to get
>>> anything done.  This would provide the flexibility (likely all the
>>> flexibility) and yet would prevent a developer from making a fairly large
>>> set of mistakes.
>> 
>> That is a very interesting proposal as well.
>> 
>> Why don't we list the types of text input control scenario's we're interested in (the force all caps case is one I wouldn't have thought of, I'm sure you've seen tons of others in your time developing apps). Once we've got something of a comprehensive list, I think a clear solution that weighs the pros / cons will become more obvious to us.
>> 
>> Richard
>