MLeader Style "Text Style" Option Not Applied

sfretwell
edited August 2019 in 2D Drafting

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.

  • sfretwell
    edited August 2019

    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. 1

    On what I would expect to be a completely unrelated note, my Text styles are also set to Romans with the same height.
    Fig. 2

    Invocation of MTEXT creates a multiline text object with the proper font
    Fig. 3

    Invocation of MLEADER does not
    Fig. 4

    As 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. 5

    Ultimately, 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).

  • Thanks for your explanation. This problem does not occur in V18.2.20. You are probably right: this looks like a bug.