Create text frames around multiple text components

[f_furger]

It would be great if you could create a dynamic text frame around several text components in the Civil caption styles. At the moment this is only possible around individual text components. The problems become fast obvious:

The problem is that certain information MUST be displayed in different components (different component types in pipe networks, for example, or if different text heights are to be used).

If it were possible to create a frame over several components, the combined area of all components would also always be displayed cleanly with a background overlay.

[TimYarris]

Hi @f_furger ,

Good suggestion. Would you expect that the Border options from the components on the Layout tab be added to the General tab (see below)?

If so, how would you expect the two to work together? For example, should border settings from the General tab override the components' border settings, or should the settings from both places be applied (potentially resulting in borders/masks for both the overall label and the individual components)? 

[f_furger]

Hi @TimYarris 

I think the best approach would be to move the components into a kind of group and draw a frame around this group.
If the components are not in a group, the frame will continue to be drawn normally around the individual components.

What do you think?

[TimYarris]

@f_furger we can do some research on the group approach.

It seems one could accomplish that by adding the various properties into a single label component. For example, adding the three properties in your example above into a single label component. The downside is that this would be limit control over the individual properties within the component.

[f_furger]

@TimYarris That's what I thought too. The grouping should be cross-component. Then you would still have the full functionality of the individual components (e.g. different text heights etc.). 

[ChrisRS]

@TimYarris, it is nice to see you participating here!

@f_furger, It is a workaround, but you can come pretty close. (You probably know all of this.)

This is a pretty complicated workaround.

Okay, this is kludge - Rube Goldberg would be proud of it.

(A) Is a label with 3 text component. "Text 1" is actually 3 lines. There needs to be something on the third line; a space will do. Text 1 = "Text1\P\P " there is a space after the last P.
          "Text1" has  Border: Visibility: True and Border: Background Mask: True.

"Text 2" is a separate component and floats above the 3 line "Text 1".
          Middle Left of "Text 2" is anchored to Middle Left of "Text 1" 

          "Text2" has  Border: Visibility: False and Border: Background Mask: False.

"Text 3" is a separate component and floats above the 3 line "Text 1".
          Bottom Left of "Text 3" is anchored to Bottom Left of "Text 1" 

         "Text3" has  Border: Visibility: False and Border: Background Mask: False.

This is automatic, but not perfect.

(B) Is a same label style, but Text 2 is too long. This problem could occur with Text 3 as well. I can not account for this automatically. 

(C) Corrects the situation on (B) by editing (override) the "Text 1" text. Pad the right with spaces. Since trailing spaces are automatically deleted, add a "." (period) at the end of the padding.
(If you know that Text 1 will always be short, you can add padding (spaces and period), within the style definition itself.

(D) An invisible "non-breaking space" (Alt+255) can be used to terminate the padding and look nicer.

Notes:

1. The line spacing can be fine tuned using Y offset.
2. This can be simplified in cases where some of the text components can be combined. When multiple lines of text are in the same component, the box will expand horizontally to accommodate all of the text.
3. Again, this is a kludge. I would be thrilled to see Civil 3D include a better solution.

[MMcCall402]

You can usually copy the contents of the text component editor, paste it into a piece of Mtext, edit the formatting there, copy and paste it back into the text component editor and the formatting will paste in as well.

[troma]

If the "dragged state" is set to "Stacked Text" then you can accomplish a border around multiple components together.

But you can't have different text heights. And it is required that you drag your label.

[tcorey]

Include the various labels into a single label component. The box will enclose all text. You can format that text on the Format tab of Text Component Editor - Contents.

[f_furger]

@ChrisRS @MMcCall402 @troma @tcorey These are all great suggestions and feasible workarounds. The problem is, for the "normal" user this is too much complicated. Therefore, the "problem" should be fixed at the top level (i.e. by Autodesk).

With my request it is important that you can work effectively with different components, because, for example, in the planning of pipe networks. There we need different components => "Text for all" / "Text". As soon as you have different components there, copying the formulas no longer works. Ans in addition, one would also like to need different text heights anyway (also with the same component type).

[ChrisRS]

@f_furger, you are preaching to the choir.

I can not speak for the others, but I certainly agree that the workarounds suggested are not the fix that Autodesk can provide.

You are lucky that this has caught the attention of @TimYarris.

I have been in this industry since college school c. 1973.

• In my board drafting days, I would have absolutely rejected "is" and drawn "should be." In dense drawings, I might have notched the upper right of the box to avoid blocking more information than needed.
• Today, I might just say that that "is" is not pretty, but that the meaning is pretty clear. "is" is serviceable for a production drawing. "should be" would ne nicer, but may not necessary.
  (I think that the "is" box misalignment fix would be pretty simple.)

Everything should be made as simple as possible, but not simpler.
attrib. Albert Einstein

Civil 3D is what it is. I often feel that I have more workarounds than workflows.

Label Style formatting has some limitations. This leads to situations where you need to chose between either "simple, but not what I want" or "complex".

Thoughts on the "normal" user and complexity: 

• Ideally*, the "normal" user should be placing labels and assigning them an appropriate style from the template in use. The "normal" user user need not be aware of, or exposed to, the underlying complexity of the style. A label style should be a "magic black box". A minimal amount of text overrides might be necessary. 
• Ideally*, label style development and maintenance would be tasks for the "Cadd Mangers" or "Power Users", or paradoxically, "cheap Interns that know neither drafting nor engineering."
• Ideally*, styles should not be modified in production drawings that "normal"
   user work on.

*I do not speak for Autodesk, but I think that this is their position. I am currently a one man shop so I wear all of these hats. Ideally, template and style development should be closer to a one time thing, than to a continuous process.

Regarding the workarounds and an Autodesk "fix"

• I think that, from the Autodesk perspective, this is kind of a "fit and finish" issue rather than a significant "mechanical" issue. To me, and possibly Autodesk, "mechanical" issues might take higher priority.
• I can not recall any significant changes having been made to the label style engine. This likely means old code. The staff/capability to work on this code may be limited.
• There are other ideas regarding label styles. It is likely that when Autodesk decides to work on label styles, they will address many ideas simultaneously. This creates a larger programming task. One idea is to expose Civil 3D entity information to the Field engine. This would let Label styles be replaced by Mleaders and Mtext. This could also make many label styles become unsupported legacy code. Be careful what you wish for. (I think Project Explorer pretty much shuts down and Autodesk interest in directly addressing Table ideas.)
• This idea competes with "bug fixes", "new design capabilities", "Infrawoks", "Collaboration", "Marketing"*, etc. The Civil 3D teams needs to balance these interests when allocating their resources.
  *"How many state DOT Directors will buy Civil 3D because it can "Create Text Boxes Around Multiple Text Components?"
• This will likely take time (years). I hope that I am wrong. In the interim, you need to chose between "not pretty" or "workarounds."

More regarding workarounds:

1. I have used @MMcCall402's cut and paste trick in the past but did not realize it could be used to support different text height. Great Tip!
2. With regard to my previous comment/workaround.
   If you know which text component will be longer, you can make that be your "host" element. In your example, Line 2 would be the host. That component would have just a space on the first line, the text on the second line, and a space on the third line.

<END OF RANT>

Good Luck!