The points-to-text-height formula that I proposed earlier turned out to be a
myth in this context. The height is proportional to the point size, no doubt
about it, but the points-to-height factor depends upon the font that it is
used. An example: to get a 15 point text on a map at the 1:15000 scale, the
"straight" factor would give a height of 79.625 meters i a metric projection
map. If that height were used, one would get a 13 point text with "Arial".
Using the technique I outlined to get the height from a specially created
text object, the height should be 95.25 (and that produces a 15 point text).
If one wanted to use "Courier New" instead, the actual height should be
87.3125. Using the height defined for "Arial" will produce a 16 point text.
I do not know how fonts are defined; I guess that a standard height is
provided in which all characters will fit and that this height is more or
less filled by the glyphs. But one thing remains is that if a conversion
factor* between theoretical height (from the map scale and the number of
points) and the text height is not provided for each font to be used in MI,
then everyone will have to experiment for finding the proper height to use.
I assume that there may be a linear relationship and that a single "slope"
factor would be enough (in the worst case with an added intercept) and that
relationship should hold whatever be the point size.
I have however found a disturbing behaviour of the createtext() function. I
wanted to create a 40 pts text (as the current font was specified to be).
Using the function and inserting the object in the table, I got a 39 pts
text and height-width of 0.002214 - 0.01028 (in degrees). Using those values
in the create text statement, I indeed got a 39 point text. After
readjusting the text to 40 pts, I got a new height-width specification of
0.002213 - 0.012335, a decrease in height and an increase in width. And that
got the create text statement to produce a correctly sized text.
I was aware that there was some rounding problems (in TTF pts size is a
continuous variable). I do not know what MI does when displaying text at a
given map scale, is it using some rounding procedure in the display, in the
reported size? I am also surprised by the role of width in the last example;
height does not seem to be the only player as I was lead to think, width has
also its import.
It seems that this topic raises many more questions than those directly
posed by the original query. But this looks perhaps like nitpicking for most
of you, only those playing with precise text output are put out by it.
Previous message slightly modified
1 point = 1/72 of an inch 5 points > 5/72 of an inch.
At scale 1:50000, that would represent 50000 * 5 / 72 inches >~ 88.4722
meters.
The difference between y1 and y2 should thus be 88.5 meters. That between X1
and X2 is more problematic. If it is not wide enough to house the text, the
text will appear but the behaviour of this object will be erratic at edit
time in particular (part will not refresh etc...). If it is too long, it may
interfere unduly with nearby objects. But the height of the text itself will
not be affected.
Empirical solution
Preparation:
1 - set your mapper at the 1:50000 scale and locate a point close to the
left edge and at mid height>CX,CY
2 - set the current font for the mapper at 5 points of the desired font
without the previous calculations.
MapBasic window
Set coordsys table <your_table>
Dim o as object
o=createtext(frontwindow(),CX,CY,"test de texte",0,0,0)
dim difV as float
dim difH as float
difV=objectgeography(o,4)-objectgeography(o,2)
print "Height "+str$(difV)
difH=objectgeography(o,3)-objectgeography(o,1)
print "Width "+str$(difH)
optional
create text into window frontwindow() "test de text" (CX,CY+difV) (CX+difH,
CY) font ("Arial",0,0,0)
Jacques Paris
---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 3003
