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 <l...@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@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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
