Convert texts that are close to each other into Mtext

[oli-123]

Would it be possible to select all the text objects within a drawing and then convert those that are close to each other into individual Mtext? I'm trying to figure out a fast way to do this with hundreds of Mtext.

See attached sample drawing in case you need it.

[Kent1Cooper]

Because of the comparative lengths, this is what TXT2MTXT does with a selection of a nearby group of 3:

Is it important that the originals are on separate lines in the result, i.e. that Text 2 goes on a new line?

[radu_609]

Yes, every original text has to be on a separate line when they are merged to mtext.

[radu_609]

Hello! I was wondering if you had any luck with that lisp to convert nearest 3 texts.

[Kent1Cooper]

A complication:  If done with TXT2MTXT, it would be necessary to go into the SEttings option, which brings up a dialog box, where you would choose to not do word wrapping, and to force uniform line spacing.  Sadly, since that's an Express Tool and not a native AutoCAD command, there doesn't seem to be a command-line way to set those options without the dialog box, and however they are remembered, it's not with System Variables that you could set.

Would the theoretical three Text objects always be of the same Style and Height and Rotation?  If so, it should not be difficult to have a routine build a new Mtext object, rather than combine the originals into one.

[radu_609]

Yes, the three text objects are always having the same style, height and rotation. I don't have any problem to create a new  mtext that combines these 3 text objects as long as I cand use it on multiple text objects at once (just lile in the example).

[gilberto.liraV9VSW]

how can i modify this LSP to do 4 text in close proximity? I have a project with over 300 labels but currently I'm txt2mtxt individually, so time consuming. I tried the 2 text and it worked but it split them into 2 seperate Mtext. 

[gilberto.liraV9VSW]

Here is my sample dwg. 

[Kent1Cooper]

See Message 7.  In this kind of situation:

if, for example, either the 2445-15 or 2445-16 Text object is the "current" one, and object selection is "reaching out" around it looking for other nearby Text objects, if it reaches out far enough to find the bottom one in its own group, it will also find at least 3 if not all 4 of the group above.  If it reaches out in small steps until it finds 3 additional objects [though not all groups have 4 -- another complication], at least one of them is sure to be in the group above, and it will miss at least the bottom one in its own group.

Filtering by color could limit, but not eliminate, those kinds of proximity selection errors.

Is there enough regularity in these to use their content as the basis for which ones do the reaching out?  Only those that start with a 2?  Would no others ever start that way?  [I didn't investigate the entire drawing.]  If that's a reliable criterion, the "reaching out" could extend downward only, rather than in all directions.

But then there are a few groups like this, which doesn't include the same kind of "header" Text as almost all others:

And should groups like these turn into left-aligned Mtext like most of the groups, or should the non-alignment remain somehow?  [They're not right-justified, either.]

Really insurmountable:

I'm just having a hard time imagining a set of relationship and/or content criteria that could be counted on to find only the ones you really want to join together, and omit others, but maybe you can delineate something.

[Sea-Haven]

There was a post about making bounding box of a group of objects stops looking when a gap, posted here no idea if that may be a way to grab common objects. Trying to find again thought I had saved a copy BBOX ?

Also convert red text to red layer, green text to green layer helps a bit in searches. There is a gap then. 

Doing a offset bounding box looking for touches may work but a huge recursive search need to remove object from master list so gets faster the further it looks.

[DZimmerKVJT2]

This lisp gives me:

error: Exception occurred: 0xC0000005 (Access Violation)

Then brings up the .ucs command. 

I know this a few years old now. It's now the future, and i've come here after I tried using ChatGPT to write me this lisp/ Unfortunately. ChatGPT tried and failed numerous times. 

I'd think that this would be an extremely simple lisp - but then again, it's not like I can do it! I was thrown off by how confident our robot overlord was.

I have attached the AI's latest attempt. 

Please help me

@Kent1Cooper 

@oli-123 

[Kent1Cooper]

It still works for me in the original sample drawing.  Can you post a [small] drawing in which the error occurs?

[DZimmerKVJT2]

Sure Kent. BTW, I'm using Vanilla 2022. I've tried four or five lips that should've worked, and based on the error msgs I'm getting, I wonder if I need a repair or reinstall. 

This is part of my endeavor to develop a Dynamo graph(s) to automate the process of:

1) using 2D CAD lines to generate rooms in Revit [I've successfully done this a few times on a small scale. I can't replicate that success)

2) populate those rooms with the 'dumb' ACAD text info from the same source .dwg. Room name and number.

Thank you for looking into this!!

[Kent1Cooper]

I'm not getting your error message, but it's not "finding" anything, since yours are all Mtext objects and it's designed for [plain] Text.

[DZimmerKVJT2]

Oh, then explode them. As I noted, i'm just trying to get the groups of texts/mtexts to combine.

I've tried it with them all as mtexts, all as texts.

[Kent1Cooper]

When I Exploded them, pairs worked [I didn't try it on the 4-item sets], though for those in which the upper one is underlined, they retain the %%U prefix for underlining that Exploding gives to the contents.  That triggers underlining in plain Text, but is not recognized in Mtext.  So something should probably be done to account for that.  Might there ever be other kinds of formatting?

Regular TXT2MTXT could be made to apply, and it keeps the underlining as originally, though it loses the relative center justification in the result [the originals are not center justified, anyway].

[DZimmerKVJT2]

Well thank you! I have a lisp to remove the underlines, and this will allow me to do the groups of two at least. I tried the ChatGPT-generated lisp again on just a few groups and still got the bad argument error:
error: bad argument type: consp #<VLA-OBJECT IAcadText 0000020391821018>

The first few iterations of the ChatGPT lisp gave me different error messages each time, but the last few had the same error message, leading me to believe there's something preventing success either on its end or my end. Idk if that makes me relieved or disappointed about what it foretells about how long we have before the Singularity occurs and we resign to serving our robot overlords 😉
Thank you again!

[Kent1Cooper]

---

@DZimmerKVJT2 wrote:
.... the ChatGPT-generated lisp again .... got the bad argument error:
error: bad argument type: consp #<VLA-OBJECT IAcadText 0000020391821018>
....

---

That error is surely coming from this combination:

(setq textObjects (vlax-ename->vla-object (ssname ss 0))) ;; the textObjects variable holds a VLA object
....

(foreach obj textObjects ;; (foreach) requires a list [the "consp" indicates a list is wanted, which it's not getting].