Sizing a text box automatically

[Eric James]

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...)

 

[Ed Bennett]

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).

 

[Eric James]

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?

 

[Ed Bennett]

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.

 

[Eric James]

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....

 

[Ed Bennett]

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.

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.