MLeader Style "Text Style" Option Not Applied
It appears that MText in a Multileader does not follow the text style specified if there's no default text:
If I specify default text for the multileader, then the settings are applied, but if I don't the MText editor defaults to the Standard text style. I've set the default MText style to the one I want, so everywhere else MText defaults to this, but just not for Multileaders:
Can someone confirm this behavior? Is there a reason for it or is this a bug?
Comments
-
It is possible to change the text font in the Mtext editor. This formatting is part of the Mtext content. If this is the case here then what you are seeing is intended behavior.
0 -
I definitely don't think that what I'm seeing is the intended behavior, so let me try to explain this better.
Here are my settings within the Multileader Styles explorer. As you can see, the font is set to Romans with the proper height.
Fig. 1On what I would expect to be a completely unrelated note, my Text styles are also set to Romans with the same height.
Fig. 2Invocation of MTEXT creates a multiline text object with the proper font
Fig. 3Invocation of MLEADER does not
Fig. 4As a workaround, though, I have found that editing the Default text option to pre-populate the MLeader MText box with some text forces the MText box to obey the default text options for the MLeader MText box.
Fig. 5Ultimately, it's the combination of the fact that I have set both the MText default settings and the MLeader default (text) settings to Romans that tells me when the MLeader is made (Fig. 4) with Arial Narrow, this is a bug. It would make some sense if the MText box for the MLeader followed the default style of MText's (Fig. 2), but since BricsCAD supplies settings to specifically format the text for a given multileader style, I would hope that those settings would actually apply. But right now it's neither; instead the font defaults to the Standard text style ("Standard"), while the text height remains correct (0.07031 for me).
0 -
Thanks for your explanation. This problem does not occur in V18.2.20. You are probably right: this looks like a bug.
0