Is there a simple way to figure out what the biggest font size is that
can display a given text string on a given size component (JLabel,
etc.)?
I'm trying to write a widget that is essentially a digital clock, but
I want the user and/or other programs to be able to resize it as
needed.  I'm extending it from a JLabel for simplicity.  Trouble is,
JLabels do not change font size when their bounding size changes.
Other than a lot of calls to getFontMetrics(getFont()).charWidth('x')
is there an easy way to determine:
1) how big a string formatted as HH:MM:SS will render (maximum height
and width for any numeric combination)
2) how big an area the JLabel allows to be painted with text (I'm
guessing something to do with the Insets, but not sure)
3) the largest font size displaying the biggest HH:MM:SS string that
can be drawn onto the JLabel without clipping it into "..."

:(
-Will

On Mar 20, 2:44 am, larkm...@aol.com wrote:
> Is there a simple way to figure out what the biggest font size is that
> can display a given text string on a given size component (JLabel,
> etc.)?

Take a look at..
<http://java.sun.com/javase/6/docs/api/java/awt/FontMetrics.html>

Andrew T.

Thanks Andrew, but I kind of hoping there would be something a little
simpler.  I've already looked at the FontMetrics as described in my
first post.  If I use that, I would have to:

1) Figure out which string is the widest and tallest of all possible
strings.  I'm betting it's likely 88:88:88 but to be safe, I'd have to
check all of them for a given font.  Some weird font might make
11:11:11 really wide.
2) Figure out how much painting area I actually have within a JLabel.
Actually, I still don't know how to find this part out!  I guess I
could just be conservative and say (width-16)x(height-16).
3) Figure out how large I could make the biggest string found in step
1 such that it would not overflow the dimensions found in step two.
Other than an experimental trial and error of create the string,
measure the string, compare against dimensions, repeat, I'm not sure
how to do this.

What I'm looking for is a way to drastically speed up this process so
I have the user resize the control on the fly without tanking the CPU.
-Will

On Mar 20, 11:24 pm, larkm...@aol.com wrote:
> Thanks Andrew, but I kind of hoping there would be something a little
> simpler.  I've already looked at the FontMetrics as described in my
> first post.  

Huhh.. I missed that important detail.

>..If I use that, I would have to:

(snip process)
...only glanced at it, but it sounds about right.

> What I'm looking for is a way to drastically speed up this process so
> I have the user resize the control on the fly without tanking the CPU.

I suspect that any method of determining
the text size, would ultimately come back
to calling those same FontMetrics methods.

This almost smacks of 'premature optimisation'.
Try it, and see if the CPU does bog down. I'll
almost bet it has no appreciable effect, if the
methods are only called when required (e.g.
display size changing*).

The only other thing I can think of to mention,
is that perhaps a JLabel is too complex a
component to be using for this particular use.
I would be tempted to simply use a JPanel and
override paintComponent() directly.

* As as aside, why and when does the diplay
size change?  Is it based upon the user
dragging the display bigger/smaller, or
is it more like a menu item that offers
a small number of preset sizes?
Something else?

Andrew T.

Well, I'm trying to write this to be flexible so I can reuse the code
in the future for other things, like generic title bars, etc.  I'm
still stumped on how to find the area to paint, but you might be onto
something with the custom override of paint().  Then I can guarantee
alignment and not worry about getting truncated to "..."  The only
killer like I said was that I'm trying to make this reusable so on a
modern 3Ghz processor it won't really matter, but trying to scale it
to some of the less powerful CPUs found on single board computers or
embedded devices could get messy.  But, it is what it is.  Thanks
again!
-Will

On Mar 20, 8:47 am, "Andrew Thompson" <andrewtho...@gmail.com> wrote:
> On Mar 20, 11:24 pm, larkm...@aol.com wrote:
>
> > Thanks Andrew, but I kind of hoping there would be something a little
> > simpler.  I've already looked at the FontMetrics as described in my
> > first post.
>
> Huhh.. I missed that important detail.
>
> >..If I use that, I would have to:
>
> (snip process)
> ..only glanced at it, but it sounds about right.
>
> > What I'm looking for is a way to drastically speed up this process so
> > I have the user resize the control on the fly without tanking the CPU.
>
> I suspect that any method of determining
> the text size, would ultimately come back
> to calling those same FontMetrics methods.
>
> This almost smacks of 'premature optimisation'.
> Try it, and see if the CPU does bog down. I'll
> almost bet it has no appreciable effect, if the
> methods are only called when required (e.g.
> display size changing*).
>
> The only other thing I can think of to mention,
> is that perhaps a JLabel is too complex a
> component to be using for this particular use.
> I would be tempted to simply use a JPanel and
> override paintComponent() directly.
>
> * As as aside, why and when does the diplay
> size change?  Is it based upon the user
> dragging the display bigger/smaller, or
> is it more like a menu item that offers
> a small number of preset sizes?
> Something else?
>
> Andrew T.

<larkmore@aol.com> wrote in message 
news:1174397161.494761.84730@y80g2000hsf.googlegroups.com...
> Well, I'm trying to write this to be flexible so I can reuse the code
> in the future for other things, like generic title bars, etc.  I'm
> still stumped on how to find the area to paint, but you might be onto
> something with the custom override of paint().  Then I can guarantee
> alignment and not worry about getting truncated to "..."

Also, if the font has numbers with different widths (which seems
fairly rare) you still need to paint each number at a fixed position.
You don't want the numbers jumping around when the time changes
the way they would on a JLabel with such a font.

>  The only
> killer like I said was that I'm trying to make this reusable so on a
> modern 3Ghz processor it won't really matter, but trying to scale it
> to some of the less powerful CPUs found on single board computers or
> embedded devices could get messy.  But, it is what it is.  Thanks
> again!

A search for the best font size will take minimal time. You
could optimize that with an initial guess based on the panel
size, followed by something like a proportional search, but
I think you'll find that a simple linear search will be plenty
fast. 

In article <1174393441.687014.66540@n59g2000hsh.googlegroups.com>,
 <larkmore@aol.com> wrote:
>Thanks Andrew, but I kind of hoping there would be something a little
>simpler.  I've already looked at the FontMetrics as described in my
>first post.  If I use that, I would have to:
>
>1) Figure out which string is the widest and tallest of all possible
>strings.  I'm betting it's likely 88:88:88 but to be safe, I'd have to
>check all of them for a given font.  Some weird font might make
>11:11:11 really wide.

If you draw the time as one single string (e.g. "12:34:56") as opposed
to drawing each single digit (and JLabel used in the straight-forward
manner would do the former) then you may also risk (weird) fonts
having compound glyphs (or whatever the technical term is) of pairs of
digits that are wider than twice the width of any one of the digits
involved.

E.g., the string "17" may draw wider than "11" _and_ wider than "77".

(Perhaps this is impossible - I don't know too much about font design
- but I wouldn't bet on it.)

To support this general case, you would have to measure the size of
all possible times from 00:00:00 to 23:59:59.


The alternative is to draw each digit separately. You then only have
to measure the size of each of the digits and you can position them as
you see fit to give the impression of them all staying in the same
place as the clock ticks along (which would also avoid any problems
you might otherwise get with proportional width fonts).

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs

Bent C Dalager wrote:
> In article <1174393441.687014.66540@n59g2000hsh.googlegroups.com>,
>  <larkmore@aol.com> wrote:
>> Thanks Andrew, but I kind of hoping there would be something a little
>> simpler.  I've already looked at the FontMetrics as described in my
>> first post.  If I use that, I would have to:
>>
>> 1) Figure out which string is the widest and tallest of all possible
>> strings.  I'm betting it's likely 88:88:88 but to be safe, I'd have to
>> check all of them for a given font.  Some weird font might make
>> 11:11:11 really wide.
> 
> If you draw the time as one single string (e.g. "12:34:56") as opposed
> to drawing each single digit (and JLabel used in the straight-forward
> manner would do the former) then you may also risk (weird) fonts
> having compound glyphs (or whatever the technical term is) of pairs of
> digits that are wider than twice the width of any one of the digits
> involved.
> 
> E.g., the string "17" may draw wider than "11" _and_ wider than "77".

That's called kerning. And you are right, the font designer is 
absolutely free to choose whatever he thinks is nice in the kerning 
table (table of pairs of characters with the space which has to be shown 
between these two characters).

Phil

Bent C Dalager wrote:
> To support this general case, you would have to measure the size of
> all possible times from 00:00:00 to 23:59:59.

For sanity reasons, no font designer would ever make this necessary 
except, perhaps, in some kind of clown font. All digits are the same 
size. UCS also includes some other characters that are guaranteed to be 
digit-sized.

-- 
John W. Kennedy
"The pathetic hope that the White House will turn a Caligula into a 
Marcus Aurelius is as na�ve as the fear that ultimate power inevitably 
corrupts."
   -- James D. Barber (1930-2004)
* TagZilla 0.066 * http://tagzilla.mozdev.org