Global Oblique Angle to Mtext

[kzD1219]

Is there a command or lisp that will easily change the oblique angle of mtext that is selected to be all the same?

I have too many dimensions that are close in size and if I can oblique certain mtext selected to the same oblique angle, that would be a huge time saver.

So we always oblique to 23.0.  And currently going into each mtext edit box and editing individually because I don't see an option on the properties dialog box once everything is selected.  Would prefer not to create a new style of mtext.

[Kent1Cooper]

It doesn't look like they need to be Mtext -- the M is for Multi-line, after all, but they're not that, if this is really representative of your need.  If you can bear to EXPLODE them into plain Text, you can then set all of them to the same obliquing angle collectively in the Properties palette.  Plain Exploding would leave the Text left-justified, but a routine could be made to preserve the source's justification and original insertion point [I have one that does so in the Text->Mtext direction, so it should be achievable easily enough in the Mtext->Text direction].

[CodeDing]

@kzD1219 ,

If you have Express Tools installed, then you can use the TORIENT Command.

EDIT:

I'm obviously addressing Rotation, which I thought was your concern. But when re-reading, I can see that is not the case lol.

Best,

~DD

[pendean]

In your screenshot, what are you calling "mtext" and what are you calling "dimensions" please? Just so we are all clear.
I assume you are using C3D or is this Map3D or just plain AutoCAD (or maybe not and why you skipped the C3D customization forum).

[kzD1219]

---

@pendean wrote:
In your screenshot, what are you calling "mtext" and what are you calling "dimensions" please? Just so we are all clear.
I assume you are using C3D or is this Map3D or just plain AutoCAD (or maybe not and why you skipped the C3D customization forum).

---

Mtext is what I have highlighted in the image (the 'orange' color).  I am using Civil3d and the distances and bearings were set up as mtext.  I could explode it to make it text, but that is not what our standard practice.  No, multi-line text really isn't needed, but works for our situations when we need to use background mask over line work.  It goes back to what prints out best on our printers/pdfs and background mask gives us the best results, not wipeout.

So globally I would like to be able to select the mtext, and just change its obliquing angle property without exploding it, due to our standards.  Not sure if that makes sense or not.  This isn't something we do all the time, but would probably do it more since it is quite time consuming.  This is a special circumstance where I have way too many bearings and distances in other parts of drawings and I want to make a distinction between the mtext that is the same size for different features.

[pendean]

---

@kzD1219 wrote:

---

....Mtext is what I have highlighted in the image (the 'orange' color)...

---

I'm not sure you answered the questions I posed: For the one important Q, do you want ALL of this Mtext to be oblique

Or just this back portion

Or front portion

And this loner?

https://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/lisp-to-change-oblique-angle-in-text...

https://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/text-selection-set-using-50-rotation...

https://www.cadtutor.net/forum/topic/4345-that-obliquing-text/

https://cadtips.cadalyst.com/edit-text/rotate-and-oblique-text 

[kzD1219]

---

@pendean wrote:

---

@kzD1219 wrote:

---

....Mtext is what I have highlighted in the image (the 'orange' color)...

---

I'm not sure you answered the questions I posed: For the one important Q, do you want ALL of this Mtext to be oblique ...not all mtext, just the mtext I select.  Some mtext in that style/layer will stay as is, when it get congested, that is when using oblique angle of 23 makes other distances and bearings stand out.

Or just this back portion... it would be the entire piece of mtext in this case, but it would be better to be able to select the mtext that needs to be changed.  Sometimes it is bearings and distances, others it is distances or bearings or areas.  

Or front portion

And this loner?  Yes that is a loner, but would need to change it.

I actually finished the area I needed to update, but here it is so you can see.  I have multiple places where it is the same color/layer style text, but in order to make it less confusing, changing some to an obliquing angle, helps distinguish between.  Does that make sense?  I can easily do it, but it just takes time.  Certainly not as easy at text, but again don't want to change the standard way we are doing things. 

[Kent1Cooper]

Something like this, perhaps [in simple terms, minimally tested]:

(defun C:OMT ; = Obliquify MText
  (/ ss n mtdata txt)
  (if (setq ss (ssget "_:L" '((0 . "MTEXT"))))
    (repeat (setq n (sslength ss))
      (setq
        mtdata (entget (ssname ss (setq n (1- n))))
        txt (cdr (assoc 1 mtdata))
      ); setq
      (entmod (subst (cons 1 (strcat "{\\Q23;" txt "}")) (assoc 1 mtdata) mtdata))
    ); repeat
  ); if
  (prin1)
)

It assumes there is originally no internal formatting -- getting it to coordinate with any such thing already present [color, font, etc. formatting] could be a real challenge because nested formatting can get complicated, though you could try and see if it works to just plant the obliquing code around everything else [I have not tried].

[ronjonp]

@Kent1Cooper Perhaps add a filter to remove the possibility of selecting mtext that already contain the internal formatting: 

(setq ss (ssget "_:L" '((0 . "MTEXT")(1 . "~{\\Q23;*}"))))

[Kent1Cooper]

Yes, if the idea is to prevent double-obliquing something you've already done it to, if that's the only thing that's been done to it.  But there's the pesky possibility of more than one aspect of internal formatting, in which the obliquing might not be the first entry, and its concluding curly bracket might not be at the very end of the content....  I wouldn't be sure how many possibilities could easily be covered.  That's why I chickened out and assumed no already-existing internal formatting.

[ronjonp]

@Kent1Cooper 

Understood. Internal MTEXT formatting codes have always been a 'challenge'.