Re: FormattedHeight of a field and its contents

[Bob Sneidar via use-livecode]

Fonts have natural margins that vary widely. A decorative or cursive font may 
have ascenders and descenders much higher and lower than a book typeface. That 
means the leading between the lines needs to be larger. I use display font for 
the labels for my forms, called Verdana has an automatic 16 point margin at 14 
point font size, even though there is nothing about the font itself requiring 
it! It's just how the font is done. 

Bob S


> On Feb 3, 2018, at 09:12 , Ralph DiMola via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> David,
> 
> Nice I've been wrestling with this. I am going to see how your 
> observations translate into mobile. I'm going to apply your of findings to my 
> app and see if I get better results than I get now. There have been a few 
> threads in the past few years addressing vertically centering text in a 
> field. None of them seem to address all font size cases. This 6px thingy 
> might explain a lot! 
> 
> Thanks again for all your work.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
> Of David Epstein via use-livecode
> Sent: Friday, February 02, 2018 9:38 PM
> To: use-livecode@lists.runrev.com
> Cc: David Epstein
> Subject: Re: FormattedHeight of a field and its contents
> 
> Thanks for the responses on this.  I used Bernd’s tool and did some more 
> tests, and found some things that may be helpful to others.
> 
> While the left and right margins of a field are meant literally (a 5 pixel 
> left margin leaves 5 white pixels to the left of the text), the top margin is 
> more complicated, no doubt owing to the variety of textHeights that need to 
> be accommodated.  For example, a margin of "0" will often clip the top of the 
> text--as if "0" meant a "negative margin".
> 
> 6 seems to be a magic default value for a field's top margin, which avoids 
> clipping the content.  With horizontal gridlines visible, a 6 pixel buffer 
> makes the top row the same height as the other rows.  And with a 6 pixel 
> buffer the formattedHeight of the field will exactly match the 
> formattedHeight of the field's content (although a non-zero borderwidth or a 
> horizontal scrollbar changes this).
> 
> Thus--what I wondered about in my original post--with a margin less than 6 
> the formattedHeight of the field is less than the formattedHeight of the 
> content; the content is in effect clipped.  At smaller textHeights this will 
> be visible, while at larger textHeights only white space above the characters 
> is clipped.
> 
> I was trying to answer two questions, and I think I'm pretty close.
> 
> 1. How do I make sure that the field's contents are all visible if I set the 
> field's height to the formattedHeight?  Answer: Set the top and bottom 
> margins to 6. For the left and right margins, even 1 pixel should be enough 
> to keep everything visible.
> 
> 2. What margins will provide a symmetrical look for a text box?
> A top margin of 6 doesn’t look like a 6 pixel margin; how it looks depends on 
> the textHeight.  I estimate that its apparent height is one fourth of the 
> effective textHeight, and I use this to size the other margins in the 
> “tightMargins” handler below.
> While the top margin of 6 looks good with horizontal gridlines, without them 
> (and especially if you show a text baseline) it looks too small compared to 
> the space between subsequent lines.  To match that larger space, in effect 
> doubling the apparent top margin, add one third of the effective textHeight.  
> See “niceMargins” handler below.
> 
> Example of usage:
> set the margins of fld 1 to the niceMargins of fld 1 set the height of fld 1 
> to the formattedHeight of fld 1
> 
> getProp niceMargins
>   put the effective textHeight of the target into t
>   put round(t*7/12) into m1
>   put round(t/3) into m2
>   return m1,6+m2,m1,m1
> end niceMargins
> 
> getProp tightMargins
>   put round(.25*the effective textHeight of the target) into m
>   return m,6,m,max(6,m)
> end tightMargins
> 
> Improvements to these are welcomed.
> 
> David Epstein
> 
> 
> ___
> 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
> 
> 
> ___
> 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

___
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

RE: FormattedHeight of a field and its contents

[Ralph DiMola via use-livecode]

David,

Nice I've been wrestling with this. I am going to see how your observations 
translate into mobile. I'm going to apply your of findings to my app and see if 
I get better results than I get now. There have been a few threads in the past 
few years addressing vertically centering text in a field. None of them seem to 
address all font size cases. This 6px thingy might explain a lot! 

Thanks again for all your work.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
David Epstein via use-livecode
Sent: Friday, February 02, 2018 9:38 PM
To: use-livecode@lists.runrev.com
Cc: David Epstein
Subject: Re: FormattedHeight of a field and its contents

Thanks for the responses on this.  I used Bernd’s tool and did some more tests, 
and found some things that may be helpful to others.

While the left and right margins of a field are meant literally (a 5 pixel left 
margin leaves 5 white pixels to the left of the text), the top margin is more 
complicated, no doubt owing to the variety of textHeights that need to be 
accommodated.  For example, a margin of "0" will often clip the top of the 
text--as if "0" meant a "negative margin".

6 seems to be a magic default value for a field's top margin, which avoids 
clipping the content.  With horizontal gridlines visible, a 6 pixel buffer 
makes the top row the same height as the other rows.  And with a 6 pixel buffer 
the formattedHeight of the field will exactly match the formattedHeight of the 
field's content (although a non-zero borderwidth or a horizontal scrollbar 
changes this).

Thus--what I wondered about in my original post--with a margin less than 6 the 
formattedHeight of the field is less than the formattedHeight of the content; 
the content is in effect clipped.  At smaller textHeights this will be visible, 
while at larger textHeights only white space above the characters is clipped.

I was trying to answer two questions, and I think I'm pretty close.

1. How do I make sure that the field's contents are all visible if I set the 
field's height to the formattedHeight?  Answer: Set the top and bottom margins 
to 6. For the left and right margins, even 1 pixel should be enough to keep 
everything visible.

2. What margins will provide a symmetrical look for a text box?
A top margin of 6 doesn’t look like a 6 pixel margin; how it looks depends on 
the textHeight.  I estimate that its apparent height is one fourth of the 
effective textHeight, and I use this to size the other margins in the 
“tightMargins” handler below.
While the top margin of 6 looks good with horizontal gridlines, without them 
(and especially if you show a text baseline) it looks too small compared to the 
space between subsequent lines.  To match that larger space, in effect doubling 
the apparent top margin, add one third of the effective textHeight.  See 
“niceMargins” handler below.

Example of usage:
set the margins of fld 1 to the niceMargins of fld 1 set the height of fld 1 to 
the formattedHeight of fld 1

getProp niceMargins
   put the effective textHeight of the target into t
   put round(t*7/12) into m1
   put round(t/3) into m2
   return m1,6+m2,m1,m1
end niceMargins

getProp tightMargins
   put round(.25*the effective textHeight of the target) into m
   return m,6,m,max(6,m)
end tightMargins

Improvements to these are welcomed.

David Epstein


___
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


___
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

Re: FormattedHeight of a field and its contents

[David Epstein via use-livecode]

Thanks for the responses on this.  I used Bernd’s tool and did some more tests, 
and found some things that may be helpful to others.

While the left and right margins of a field are meant literally (a 5 pixel left 
margin leaves 5 white pixels to the left of the text), the top margin is more 
complicated, no doubt owing to the variety of textHeights that need to be 
accommodated.  For example, a margin of "0" will often clip the top of the 
text--as if "0" meant a "negative margin".

6 seems to be a magic default value for a field's top margin, which avoids 
clipping the content.  With horizontal gridlines visible, a 6 pixel buffer 
makes the top row the same height as the other rows.  And with a 6 pixel buffer 
the formattedHeight of the field will exactly match the formattedHeight of the 
field's content (although a non-zero borderwidth or a horizontal scrollbar 
changes this).

Thus--what I wondered about in my original post--with a margin less than 6 the 
formattedHeight of the field is less than the formattedHeight of the content; 
the content is in effect clipped.  At smaller textHeights this will be visible, 
while at larger textHeights only white space above the characters is clipped.

I was trying to answer two questions, and I think I'm pretty close.

1. How do I make sure that the field's contents are all visible if I set the 
field's height to the formattedHeight?  Answer: Set the top and bottom margins 
to 6. For the left and right margins, even 1 pixel should be enough to keep 
everything visible.

2. What margins will provide a symmetrical look for a text box?
A top margin of 6 doesn’t look like a 6 pixel margin; how it looks depends on 
the textHeight.  I estimate that its apparent height is one fourth of the 
effective textHeight, and I use this to size the other margins in the 
“tightMargins” handler below.
While the top margin of 6 looks good with horizontal gridlines, without them 
(and especially if you show a text baseline) it looks too small compared to the 
space between subsequent lines.  To match that larger space, in effect doubling 
the apparent top margin, add one third of the effective textHeight.  See 
“niceMargins” handler below.

Example of usage:
set the margins of fld 1 to the niceMargins of fld 1
set the height of fld 1 to the formattedHeight of fld 1

getProp niceMargins
   put the effective textHeight of the target into t
   put round(t*7/12) into m1
   put round(t/3) into m2
   return m1,6+m2,m1,m1
end niceMargins

getProp tightMargins
   put round(.25*the effective textHeight of the target) into m
   return m,6,m,max(6,m)
end tightMargins

Improvements to these are welcomed.

David Epstein


___
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

Re: FormattedHeight of a field and its contents

[Paul Dupuis via use-livecode]

What version of LiveCode on what platform are you trying this on?

There have been a number of bugs related to object geometry
calculations, including fields, over the years, found and fixed in
various releases of LC. Some were platform and version of OS specific.

On 1/31/2018 8:31 PM, David Epstein via use-livecode wrote:
> Is there somewhere an explanation of how a field’s textSize, borderWidth, 
> margins, and formattedHeight interact?  
>
> According to the dictionary entry for “formattedHeight”, a field’s 
> formattedHeight is calculated “including top and bottom margins”, while the 
> formattedHeight of a chunk is calculated “disregarding margins.”
>
> That does not seem consistent with these results for a field whose textSize 
> is 16 and whose margin is 4:
>
> the formattedHeight of line 1 of fld 1 19
> the formattedHeight of line 1 to 2 of fld 1  38
> the formattedHeight of fld 1   15  if there’s one 
> line of text
> the formattedHeight of fld 1   34  if there are 
> two lines of text.
>
> Even though there are top and bottom margins of 4, the field’s 
> formattedHeight is smaller, rather than larger, than the formattedHeight of 
> its contents.
>
> A perhaps related question:  Why does a field margin of zero clip the visible 
> text at the top and left?
>
> Many thanks.
>
> David Epstein
> ___
> 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



___
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

Re: FormattedHeight of a field and its contents

[Bob Sneidar via use-livecode]

I get 14 for line 1 and 22 for the field. Put that in your smipe and poke it! 
;-)

Bob S


> On Jan 31, 2018, at 17:31 , David Epstein via use-livecode 
>  wrote:
> 
> Is there somewhere an explanation of how a field’s textSize, borderWidth, 
> margins, and formattedHeight interact?  
> 
> According to the dictionary entry for “formattedHeight”, a field’s 
> formattedHeight is calculated “including top and bottom margins”, while the 
> formattedHeight of a chunk is calculated “disregarding margins.”
> 
> That does not seem consistent with these results for a field whose textSize 
> is 16 and whose margin is 4:
> 
> the formattedHeight of line 1 of fld 1 19
> the formattedHeight of line 1 to 2 of fld 1  38
> the formattedHeight of fld 1   15  if there’s one 
> line of text
> the formattedHeight of fld 1   34  if there are 
> two lines of text.
> 
> Even though there are top and bottom margins of 4, the field’s 
> formattedHeight is smaller, rather than larger, than the formattedHeight of 
> its contents.
> 
> A perhaps related question:  Why does a field margin of zero clip the visible 
> text at the top and left?
> 
> Many thanks.
> 
> David Epstein

___
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

Re: FormattedHeight of a field and its contents

[BNig via use-livecode]

Hi David,

have a look at
http://berndniggemann.on-rev.com/margins/marginsapp.livecode.zip

It does not explain why but shows what influences the formattedHeight of a
field when changing margins, border size, scrollbars, text height etc.

Kind regards
Bernd



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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