What is up with FormattedHeight?

[Howard Bornstein]

Thanks for your reply. As a graphic designer, I know about ascenders,
descenders, x-height, etc. However, I had thought that formattedHeight
adjusted the field height to the size of the text being displayed, not to
the min and max of the entire type face.

I created a field with the entire extended ascii set in it and chose
formatted height. While the bottom border hit the descenders, the upper
border still had noticeable space above the highest character in the full
character set. It turns out that this is because of the textheight
property. This sets the vertical distance between one baseline and the
next. This is set by default to 4*textsize/3 in order to provide a
reasonable distance between lines (i.e. the "leading").

In order to make the formattedheight fit (almost) properly around the full
range of a typeface you have to set the fixedLineHeight to true and then
set the textheight to the same value as the textsize (rendering the
effective leading as zero).

However, it's more complicated than that.

The proper display of text is a field is also contingent upon the field
margins. If you set the margins to 0, the descenders start to get cut off
when the text size is around 40 points. LC tries to make this invisible to
the average user by setting the default margins to 8 (they recommend
nothing less than 2 in order to take into account the focus border of the
field). However, formattedHeight doesn't automatically adjust these margins
for you so that the text is always displayed properly. You have to do this
manually.

So to recap, it appears the the formattedHeight property determines the
displayable height of text in a field based on the metrics of the entire
type face, not just the type that is displayed. It uses the textheight
property (if set) and the margins properties (if set) as part of the soup
that gets mixed together when displaying type. At large type sizes, the
settings for the margins don't seem to be predictable to make sure that
text is not cut off at the bottom.

Given this, the only value I can see for formattedHeight is that it
guarantees that the field will provide "sufficient" room to display the
type. That's about it. And even that breaks down with large type sizes and
small margins.

Since LC does ultimately display the text as graphics on the computer, I
had hoped it would have sufficient information to know exactly where the
text boundaries are, but if it is using the operating system to actually
display the text, then it probably wouldn't have this level of
pixel-resolution information available.

So it appears that it will not be easy to determine the minimum rectangle
to encase text of any given font at any given size. I still have a couple
of ideas to approximate this but if anyone else wants to take up the
challenge, I'd be interested to hear what you come up with.

Thanks for all the replies.

On Mon, Feb 6, 2012 at 1:13 AM, Paul Hibbert <lc at pbh.on-rev.com> wrote:

> Howard,
>
> > 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.
>
>
> There is a great deal more information contained in any font than the
> characters you see on screen.
>
> 1234 as you used  for your test are all similar height characters, but
> consider chars like 'Å' and 'g' that need more room to display their
> information.
>
> Each character is sat on a baseline, but has clear space above and below
> so they are readable when typed into a paragraph, 100 pt type doesn't
> measure 100 points from the bottom of an individual character to it's the
> top, but is more often (not always) measured from the top of the highest
> ascender within the font to the bottom of the lowest descender of all the
> characters within the font, so you are not seeing the full picture with
> typing '1234'.
>
> Every font has it's own totally unique set of relationships and parameters
> for baseline, line height, x-height, ascenders, descenders etc. So, as you
> can probably imagine, any adjustments you make for say Helvetica will be
> totally different for a font like Brush Script.
>
> From my experience of working with type for over 35 years, both off and on
> computers, I really don't think LiveCode (or any other application) could
> do what you are asking without first converting the displayed text to a
> graphic (either vector or bitmap) and then processing the resulting
> information.
>
> Regards,
>
> Paul
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
Regards,

Howard Bornstein
-----------------------
www.designeq.com