OpenNurbs v 7.0

I see that there is a large difference between v 6.0 Font management and v 7
Now I am a bit lost since I need to generate a series of text with specified height (in mm)
but I am unable to see how to do this.

It was quite simple in v 6

	ON_TextEntity2  *pent = new ON_TextEntity2 (  );
	pent->SetType( ON::dtTextBlock);

Can I have a hint for v 7.0 ?


Try this:

  const wchar_t* textstring = L"New text";
  const double textheight = 3.7;
  const ON_Plane plane;
  // You can use any dimstyle.
  // Passing nullptr for tjhe style will use ON_DimStyle::Default
  // If the text height and whatever else you want to tune up is set 
  // in the style you use, you don't have to set it after creating the text.
  // If you do set properties after creating the text, they will be set as overrides
  const ON_DimStyle* style = nullptr;
  ON_Text* ontext = new ON_Text;
  ontext->Create(textstring, style, plane);
  ontext->SetTextHeight(style, textheight);
1 Like

Thanks Lowell , works fine
Now the question is How to make a Dimstyle ?
I need to change a few properties but I don’t really understand where does the dimstyle
go, I don’t want to generate a dimstyle for each text generated, but only one dimstyle
and assign it to the text objects.
Basically I want to create a new dimstyle by copy of a default one and use it for all my font objects
that share same attributes. I see all the routines but a bit confused


Ok Forget my question I see that the text objects has all overrides

fine thanks

Hi Lowell
There seems to be a bug on the text orientation, after calling this code
in the image you can see the point passed and the final text position
aligned on top instead of the bottom

	if (text->Create(sztext, refDim, plane))
		text->SetAlignment(ON::TextHorizontalAlignment::Left, ON::TextVerticalAlignment::Bottom);
		text->SetTextHeight(refDim, FontH);


@gerryark - You can use
ontext->SetTextVerticalAlignment(style, ON::TextVerticalAlignment::Bottom);
I’ll see if I can figure out about SetAlignment(). I think it should be deprecated.

When taking a closer look at the picture, I imagine, that the problem is not only in the rendering code, but maybe in the font specifications of the bracket glyphs or their interpretation in the rendering code.
Apparently, the “over height” of the bracket as measured from the baseline is not compared to the normal font height. This may be easy to fix, eventually by simply ignoring the individual glyph upper length and just use the upper length of a “standard capital” to compute the offset.

May I kindly ask, to fix this, instead of deprecating it. If you do that, people may be left with the question, how to get interior properties of the font, a.k.a the individual glyph dimensions, in order to properly place the text.

If the font has no standard capital height (sorry, I’m not a font expert), I believe, ‘T’, ‘M’, ‘F’ and ‘B’ are good candidates.