There are a good number of things about AutoCAD Civil 3D Label Styles that may eclipse our previous notions about civil engineering and survey annotation. The path of totality in Civil 3D grants us all significant access to the data behind the many Features – That list of many things inside the Civil 3D Toolspace. These nuanced opportunities deliver to us the format capabilities to produce our annotation in the manners we are used to and that we come to expect. We could call that…
The Data Behind the Obvious
We easily achieve the unexpected too. This broader reality of a double planet wobbling in spiraled orbital ellipses (these paths look a lot like twisted DNA) leads to a lot of understandable Civil 3D user frustration.
“Why is that Label Style doing that?”
This happens to us all…or not. You have a choice. Pick your Civil 3D DNA.
The Framework for Civil 3D provides a deeper, richer, and more robust structure for Label Styles. Why? The Styles of the Framework must to function consistently well in multiple Civil 3D releases within the varied production performance demands of many customers and different kinds of projects. Don’t believe that is possible? Please try the Framework. Double dare you.
“I need a Label Style that does this.”
Odds are it’s in there. People simply don’t complain about the Framework’s form and function much.
That Label is Computed Not Typed
Well actually, all Civil 3D Label Styles do have type. If we cast the Hierarchy Rules of Civil 3D aside for a moment (something we can never do), I trust you can catch the drift.
Everyone in the training class nods. This is like explaining the sometimes perverse behavior of adults to a kindergarten class.
CAD users always initially have problems with the always computed reality of all labels in Civil 3D. Yeah. Automatic, annotative-scale-aware Labels are cool. They look like less work and they are.
Our CAD school and ITT tech education and history says if I type it I can fix it.
The Moon revolves around the Earth, right?
Ok. You can type it but now you have to maintain, preserve, and remember that little tweak for a long time.
Someone has to ask,
“What labels got tweaked”?
Our typed edits create a manual Text Override of the Labels that AutoCAD Civil 3D 2018 can now at last display. You may not like this new circle with an I glyph. This is a drawing property controlled in Profile>>AEC Settings>>Solution Tips area by the Drafting checkbox.
This beats the heck out of selecting Labels by type for Text Override conditions in a complex project drawing. To clear selected Text Override Labels: Right click and pick Clear All Label Text Overrides.
Yes. If it’s in a Group Label, it is faster to delete the entire Set or even just the individual Style assignment in the Set. There goes the neighborhood and your or someone else’s tweaks.
Now we’re back playing the markup game we all know too well.
Frankly, a set of Point Style Labels in a Survey Db always seems to me to be a more maintainable and better project-based QAQC solution to the Text Override problem. That says that we have to think about Description Key Sets quite differently. Maybe the Civil 3D Description Keys To Format post helps.
Better to Get the Data Right Then Format
Often that label data needs to have more than one line. People seem to struggle with this more. Now the automatic label formatting details get dicer. More factors get involved in the Label resolution. Height (hopefully resolved by saner LSD – Label Style Defaults hierarchy rules) and consistent component connections in the Label Style structure come to mind.
There’s the obvious. For most situations we can employ multiple Label Style text components to divide and conquer the problem. This is relatively intuitive like the old attributes in an LDT point block. We do have to pay attention to order and other Label geometry connections and also try to remember to make the Drag Label State work appropriately.
“I want my Label to take up this much room.”
It’s a Bit of a Drag but True
If you want multi-line labels your Label Style has to have scale sensitive properties in place. I say “scale sensitive” because these properties are related to computed font character of the Style in use, Height, the geometric structure of the label components, etc.
Some minor Style adjustment may be necessary if the annotative scales changes too much.
A small maintenance price to pay for a lot of new annotative plan set power.
In Summary But Not Well Documented
Autodesk somewhat hides away in a Label Style text component the normal state Maximum Width and the Dragged State’s Maximum Text Width properties.
A while back these only appeared in the Summary tab.
Civil 3D is still a bit inconsistent about the official property names in the object model.
The Maximum Width properties are a bit spacey. We don’t expect this.
The Maximum Width properties know nothing about typical <newline> ASCII characters because these properties are about further subdividing the strings aside from the Text Composer’s output contents.
The Maximum Width settings look for <space> characters in the text strings and break the string in the Label data as close as possible to the calculated width.
The default Maximum Width values are 0. That means you don’t care about the label width.
A Maximum Width controlled Label result requires we carefully plan ahead the available <space> character separators in the data in the final result text string.