How to verticle centre text in textbox on a label [report]

[Nifrabar]

Hi! I'm having a textbox on a report in which a number of lines may be printed [new line generated by chr(13)]. Font and fontsize is user selection. Now I'm looking for a way to vertical centre this text in the textbox. I do think that fontmetric should be able to decide height of a line. Count of the number of chr(13) decides number of lines. Height of textbox is to be retrieved by hacking the frx. Now the Q is how to get the algortm to retrieve the number of chr(13) which must be placed in front of the textstring to be printed.
Any suggestions?
TIA Bart

 

[Olaf Doschke]

occurs(text,chr(13))gives the number of carriage returns. That +1 is line numbers of the text
textfield height/fontmetric value for the line height gives the total number of lines available.
Then it's (total lines - text lines)/2 to get the number of empty lines you need to put in front.

Bye, Olaf.

 

[Nifrabar]

Hi Olaf,
Thanks for your reply. So far I could found already. But this is part of the solution. I am looking to see the relation between the result of the x*fontheight versus textbox height in the report.
-Bart

 

[Olaf Doschke]

Well, that's Pixels versus Foxels vs Inch. Lookup Foxel in the help.

If you can estimate the number of lines in your textbox, you won't need to know the conversion factor. How many lines do match into the textbox height? Isn't it fixed? If it's set to stretch with overflow, it'll always stretch and you won't have a defined fixed height anyway.

Line height is fixed, even for proportional fonts, so write out a text filling the whole height, count the lines and it won't matter to convert inches to foxels or pixels or vice versa. All you need to know in the end is the number of lines to prefix.

Bye, Olaf.

 

[Mike Lewis]

Hi Bart,

I am looking to see the relation between the result of the x*fontheight versus textbox height in the report.

Well, you know the height of the textbox because you establish that at design time. The height is fixed, unless "stretch with overflow" is switched on, in which case the problem doesn't arise (because the text will occupy the entire height).

The problem is that the textbox height is expressed in centimetres, while x*fontheight is in pixels. To convert between the two, you can use the function shown here: Convert between twips and pixels in Visual FoxPro. A twip is simply a unit of length: 1 cm = 567 twips.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Hi,
Open your report, I suppose you have VFP9Sp2 and Reportbehavior90:
Rclick on the box you would like to have its contents vertically alligned.
This will give you a contextmenu - select properties
Click on last tab Advanced
Here you will find the text rotations box.
The spinner Angle will do it for you.

Groet,

Jockey(2)

 

[Nifrabar]

Once again thanks for sharing your knowledge with me.
My user may select every label-size. Than I programmaticly make the textbox size according the labels' dimensions.
There are several lines to print on the label but my approach is to have a single string with chr(13)'s to create new lines.
So I realy do need some calculations to decide the number of 'empty' lines.
Jockey(2) I will have a look at your approach wich seems new for me.

-Bart

 

[Olaf Doschke]

That angle will control rotation, not vertical alignment. If users can determine font and fontsize, yes, you need to calculate. Again that's about foxels or twips. I'm quite sure twips are a twain only thing, foxels are related to inches in some way. The HPOS/VPOS values you find in FRXes are 1/10000th of an inch, no matter how that's called.

The font height fontsize returns won't help you, as it's for the screen and the screen dpi does not correspond to the frx dpi. Google knows another conversion factor for Postscript Font Pt to Inch as 1 Pt = 0.0138888889, so a font size of 10 should correspond to 0.138888889 inch.

Bye, Olaf.

 

[Olaf Doschke]

I found another base conversion value in the VFP help: There are 72 points in 1 inch.

Now you'd need to find out what that means for the font height, because the font size may not be the height between to baselines ( [URL unfurl="true"]http://en.wikipedia.org/wiki/Baseline_(typography)[/url] ) but it may be the height from baseline to capline or ascent or descent to ascent (refer to the illustration at wikipedia), I don't know.

Documentation is sparse about these things, but the standard height of a report control being for a single line could hint on a line height, if you put two controls directly under each other and see both VPOS values for them in the FRX you get a line height. That should grow linear with the font size, too, so you could figure out a factor for font size and line height.

Bye, Olaf.

 

[Mike Lewis]

I'm quite sure twips are a twain only thing, foxels are related to inches in some way.

No, twips are a straightforward unit of linear measure, like inches and centimetres. It's a simple arithmetic conversion.

Foxels is also a linear measure, but it is a function of the current font.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Foxels are also unique to Foxpro while Twips belong to the OS.

Foxels were actually invented along with the methodology to translate between the platform's X/Y coordinates and Foxpro's x/y coordinates when FP ran on Win/Mac. They're why we used to see "Position is off screen" errors when Foxfont was not present, even if the app did not use Foxfont. Foxpro used it in calculating Foxels.

 

[Mike Lewis]

On reflection, the question of twips is irrelevant. The function I linked to is a way of converting between pixels and inches / centimetres. The result is in turn converted to twips. That's the only reason twips comes into the picture.

So, we've got the height of the line (in pixels) from FONTMETRIC(). We've got the height of the textbox (in inches / cm), either from hacking the FRX or using the design-time value. And we've got the number of lines of text, by counting the CRs. All we need is to convert between pixels and inches / cm, which my function will do (if you ignore the final step of converting to/from twips).

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Indeed you can take PixelsToTwips from Mike, remove 1440 and have inches instead of twips. But that's not all mike, the question what height really means, if you use Fontmetric(1) is still open. Is it a line height? I'm sure it's not, is it the height of an uppercase letter? Maybe. We need to find out how much inches a line feed moves the text vertically, that's not necessarily the height of the font in inches.

Bye, Olaf.

 

[NasibKalsi]

After knowing number of lines and fontmetric() (Olaf, Mike). Add fontmetric(1,3,4,5) to get the Height of each line. For example, if you use font (Arial, 20, Normal) then fontmetric will be 44 (32+1+6+5). On a report you can print some 112 Pixcel/Inch (i tested by hit and trial). This is very close to the real number, but may need to adjust 1 pixel every 4 lines. If the box size is 2 inch high(224 pixels), and you have only 2 lines (44*2 ->88 pixels) to print with user selected font (Arial, 20, Normal). Then skip half of the difference (224 - 88), relative to the top of the TextBox.

As Olaf suggested, you can verify yourself by creating a Textbox on the report such that the height is one inch. Then calculate fontmetric() height of this font.

Your system will fail if the user selects the font beyond the TextBox size, so adjust the font size to maximum fitable.


Nasib

 

[Olaf Doschke]

I'd say it's easier to not calculate with pixels to twips, but with with the pt unit of fonts. 72 pt = 1 inch. You just have to know what a font size measures and how that relates to the line height.

Bye, Olaf.

 

[Olaf Doschke]

From what I find here [URL unfurl="true"]http://reference.sitepoint.com/css/lengthunits[/url] at least in HTML/CSS the font size is really the line height, the bistance from eg baseline to baseline of the next line, unless you don't specify a line-height differing from the font size. Then you can eg have half a line distance between lines.

So indeed the calculation from font size to inch just i fontsize*10000/72 to get to values in the same units as the Height field of the FRX of the report textbox or to the detail band height.

Bye, Olaf.

 

[Mike Lewis]

at least in HTML/CSS the font size is really the line height, the bistance from eg baseline to baseline of the next line, unless you don't specify a line-height differing from the font size.

That's certainly true in the traditional printing world. To be more exact, the height of the line is equal to the font's point size plus the leading. The leading is the additional vertical space between lines, and is also measured in points. Given there's no way of setting the leading in VFP, it's safe to assume it is always zero. In other words, line height always equals the font's point size.

But a simple experiment should confirm that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[vgulielmus]

Using SET REPORTBEHAVIOR 90 you can change dynamically the vertical position or the height of a report textbox.
faq184-7700

My respects,
Vilhelm-Ion Praisach
Resita, Romania

 

[Olaf Doschke]

I think the general idea of Bart is quite okay, using reportlistener to change things dynamically may also help, sure, but what really would help is a horizontal alignment of text with the fixed label height.

You may be able to more elegantly change a frx or lbx at runtime, but hacking the data is quite easy. You have a detail band object and can determine or set it's height according to the label size. You also add a single textbox and size it the same size. You could also make it 1 line high and stretch with overflow, then anchor it to the detail band top or bottom, but that won't get you vertical centered alignment, so calculating line height and adding some CR is straight forward and simple enough, so I'd not change the plan now, as we are short to a solution.

Mike, good point abpout the leading height, isn't there some property of a textbox defining line distances as factor of font height? Eg 1.5 lines, or am I confusing this with Word paragraph settings?
In reportmode 90 you have interesting advanced properties referring to HTML, eg HTML.Anchor and HTML.CSSClass in two varianbts to overrride or extend FRX properties. You might be able to simply set an alignment with this feature indeed, but I haven't worked with any of these advanced properties yet.

Bye, Olaf.

 

[Olaf Doschke]

[URL unfurl="true"]http://spacefold.com/articles/tmm/HTMLAdvancedProperties.aspx[/url]

It seems you can define eg vertical-align: center; and that would center the text within the report control.

Bye, Olaf.