What is up with FormattedHeight?
bobs at twft.com
Mon Feb 6 11:09:40 CST 2012
If you have ever had to edit type faces, you would see that this space is necessary. It used to be called leading (not lead as you would a dog but lead as in a bit of lead inserted between lines of type in a press). Without leading, type in a paragraph would be much more difficult to read. There needs to be room for the height of the ascender the body, the tail and the leading. The sum of all that is the formatted height.
On Feb 5, 2012, at 7:30 PM, Howard Bornstein wrote:
> I need to find the smallest rectangle that will enclose a line of text of
> arbitrary text size in a field. I thought I could use formattedheight and
> formattedwidth to do this but it doesn't seem to be working.
> The dictionary says about FormattedHeight:
> Use the *formattedHeight* property to determine how much vertical space an
> object needs.
> The *formattedHeight* of a chunk in a field is the amount of vertical space
> that portion of the field's text requires
> That's not what I get. If you'd like to follow along at home, here are
> some simple steps to show what I mean:
> Create a field in LC.
> set the showborder to true
> Set the border to 1 (this is only to show what LC thinks is the boundary of
> the field)
> Set the 3D to false
> set the margins to 0,0,0,0
> Set the fixedlineheight to off
> Set the textfont to Helvetica
> Set the textsize to 100
> Type in the following into the field "1234"
> Go to the "size and positioning" tab of the object inspector and click both
> Fit Content buttons for width and height.
> I would have expected the border to tighten down to include the text and no
> more. But instead, look at all that space at the top—and a fair amount of
> space at the bottom. Why is that space considered part of the height of the
> I can gain what I want by manually adjusting a number of properties.
> If I use the fixed line height property, I get a little more control,
> although, as far as I can tell, formattedheight should work without it, but
> it doesn't.
> If I turn on the fixed line height (i.e. the textheight property) in the
> inspector (with the configuration I described above), it is automatically
> set to a text height of 93 and the text jumps up to the top of the bounding
> box (I've got nice screen shots of all this but I seem to remember that
> we're not supposed to use attachments or images on this list).
> If I click "Fit Content" for height at this point, the box closes down and
> gets rid of some, but not all, of the space at the bottom.
> If I adjust the field height value to 73, I can finally get the bounding
> box to match the height of the text.
> This is what I am looking for. I am trying to figure out the relationship
> of settings which will always produce a bounding box with this level of
> tightness for any size text (I am ignoring the extra space on the left of
> the field for now). I need to be able to do this under script control.
> If I go through the same exercise but set the text size to 200 points, I
> can again adjust things so that the bounding box only encloses the text
> with no additional space, but I can't find any clear relationship between
> the settings for 100 points and 200 points.
> So my questions are these:
> Why doesn't the formattedHeight of a field just do this automatically? Why
> does it include extra space at the top and bottom of the field?
> What are the relationships among text size, text height, and field height
> that will allow the field to adjust to exactly the size of the text
> regardless of the text size.
> Please let me know if I'm totally missing the point about formattedHeight
> or if there is something else obvious that has eluded me.
> Howard Bornstein
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode