Sizing a text box automatically

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Eric James - 17 Jul 2006 18:16 GMT

Does anybody know how to programatically shrink the height of a text frame
so that it just fits the text inside? Two methods I've tried don't quite
work - setting the box height =text.boundheight + box margins almost looks
good but makes it too small (am I missing something here?), & shrinking the
height incrementally until just before overflow occurs works except for when
the box only contains one line of text, when overflow never occurs. Duh!
(Looks like a bug to me, that one...)

Reply to this Message

Ed Bennett - 17 Jul 2006 18:48 GMT

> shrinking the
> height incrementally until just before overflow occurs works except for when
> the box only contains one line of text, when overflow never occurs. Duh!

You could try checking if the number of lines is 1 by checking if
TextRange.Lines(1) returns the same as TextRange.Lines(2).

Signature

Ed Bennett - MVP Microsoft Publisher
http://ed.mvps.org

Reply to this Message

Eric James - 18 Jul 2006 12:31 GMT

I don't see how that will help... I can also deduce that the box has only
one line in it by reducing its size to zero and testing the overflow flag...
what I actually want to do is make the box fit the text.
Are there two bugs here in that the overflow flag doesn't work properly, and
text.boundheight doesn't give a correct value?

>> shrinking the height incrementally until just before overflow occurs
>> works except for when the box only contains one line of text, when
>> overflow never occurs. Duh!
>
> You could try checking if the number of lines is 1 by checking if
> TextRange.Lines(1) returns the same as TextRange.Lines(2).

Reply to this Message

Ed Bennett - 18 Jul 2006 15:55 GMT

> I don't see how that will help... I can also deduce that the box has only
> one line in it by reducing its size to zero and testing the overflow flag...
> what I actually want to do is make the box fit the text.
> Are there two bugs here in that the overflow flag doesn't work properly, and
> text.boundheight doesn't give a correct value?

Technically, no. The size returned by BoundHeight is actually the size
of the bounding box, it's just that Publisher requires a larger text box
to be able to contain the text without overflow (even once you add in
considerations for the text margins). When you have a single line of
text and reduce the size, the text remains in the box (as it is still
visible), it just gets chopped off, so it does not overflow.

Suggestion: Set the height to TextRange.BoundHeight + MarginTop +
MarginBottom, and if the number of lines of text is greater than one,
increment until the overflow is zero.

Signature

Ed Bennett - MVP Microsoft Publisher
http://ed.mvps.org

Reply to this Message

Eric James - 19 Jul 2006 10:20 GMT

Ed - thanks for your help with this.
I've done a few more experiments now though, and would now suggest that the
boundingheight (& also width, presumably) error is definitely a bug, as it's
related to the particular font(s) & sizes in use in the text box. Sometimes
the value is correct, which suggests to me that the problem may be caused by
a rounding error in an internal calculation somewhere. In my tests though,
adding 1 to the reported height seems to mask the problem, but it's
obviously a nasty hack.

As for the overflow flag not being set on a single line of text - I'll grant
you that may not be a bug, it could actually have been intentionally
designed that way - in which case it's a design error. The obvious question
is, why would anyone want it not to overflow the text, but instead to chop
it in half, say? And why stop at one line? Why not chop the following lines
in half as well? (This behaviour can be seen interactively also). You won't
find such silliness in Quark Xpress, etc.

I'd be grateful if you could forward these issues up the mvp channel to
Microsoft of course, not that I'd be very optimistic about them actually
fixing them....

>> I don't see how that will help... I can also deduce that the box has only
>> one line in it by reducing its size to zero and testing the overflow
[quoted text clipped - 12 lines]
> MarginBottom, and if the number of lines of text is greater than one,
> increment until the overflow is zero.

Reply to this Message

Ed Bennett - 19 Jul 2006 13:16 GMT

> I've done a few more experiments now though, and would now suggest that the
> boundingheight (& also width, presumably) error is definitely a bug, as it's
[quoted text clipped - 3 lines]
> adding 1 to the reported height seems to mask the problem, but it's
> obviously a nasty hack.

Yes. I think, however, that the bug is in Publisher's
wrapping/overflowing rather than in the value returned by BoundHeight.

> As for the overflow flag not being set on a single line of text - I'll grant
> you that may not be a bug, it could actually have been intentionally
> designed that way - in which case it's a design error. The obvious question
> is, why would anyone want it not to overflow the text, but instead to chop
> it in half, say?

But why would anyone create a text box containing no text?

> You won't find such silliness in Quark Xpress, etc.

Publisher retails for a few hundred dollars less than QuarkXPress, et al.

Signature

Ed Bennett - MVP Microsoft Publisher
http://ed.mvps.org

Reply to this Message