Split MTEXT into separate MTEXT by words.

[ChrisWebster]

Is there a way or lsp to simply split selected single (or multiple) MTEXT objects into individual MTEXT objects by words? Have the same look but be individual MTEXT objects with one word in each MTEXT object.

[ChrisWebster]

Thanks @ВeekeeCZ Awesome! That certainly does take a lot of the manual work out!

I explode the mtext,  use Lee Mac's lsp, then use TXT2MTXT with the setting to COMBINE OFF.

[john.uhden]

@ChrisWebster and @pendean ,

I've got my own @dissect function working to separate the words from the spaces in the form of a list e.g. (str1 spaces1 str2 spaces2 str3 etc.).

The next step is to determine the distance between each word by using textbox on an equivalent text entity of the spaces.  Or maybe make a copy of the original, change its rotation to 0, change its 'textstring to the spaces, change its width to 0, and get the length of its boundingbox.  I don't know yet which method would be better, except that either way will remove any internal formatting, which I trust is acceptable, that is making its textstyle definition govern its appearance, though its height override should remain since it is a property.

But wait a second.  In the dissection, internal formatting can get included as characters within each word since they are not spaces.  Perhaps I should unformat the original textstring first.  Anyone?

[john.uhden]

@ChrisWebster and @ВeekeeCZ ,

This is interesting.

I decided to try again the simpler method of exploding the mtext.

"This mtext contains formatting."

becomes...

(1 . "This ")
(1 . "mtext")
(1 . " ")
(1 . "contains")
(1 . " ")
(1 . "formatting.")

Notice how the space between "This" and "mtext" becomes the last character of "This " whereas the other spaces became separate words?  I suppose I could use (vl-string-trim " " str).

AND the separate formatting (to the extent that plain Text can replicate it) the internal formatting remains as properties, so all in all it's a much simpler operation.

[john.uhden]

@ВeekeeCZ ,

Okay, so how can I use TXT2MT via AutoLisp including changing the settings?

I can type it in at the command prompt but neither (command "TXT2MT") nor (cTXT2MT) works.

Or do I have to create/adapt my own?

[Kent1Cooper]

TXT2MTXT is an Express Tool, so an AutoLisp (command) function won't work with it.

[pendean]

---

@Kent1Cooper wrote:

TXT2MTXT is an Express Tool, so an AutoLisp (command) function won't work with it.

---

Do you mean this or something else

[Kent1Cooper]

---

@john.uhden wrote:

... neither (command "TXT2MT") nor (cTXT2MT) works. ....

---

@pendean is right -- it used to be an Express Tool, but it has obviously been made a "real" command.  But the issue quoted is from not spelling the command name in full, or if/when it was an AutoLisp routine, the second one is missing the colon after the (c .

[ВeekeeCZ · Accepted solution]

---

@ChrisWebster wrote:

Thanks @ВeekeeCZ Awesome! That certainly does take a lot of the manual work out!

I explode the mtext,  use Lee Mac's lsp, then use TXT2MTXT with the setting to COMBINE OFF.

---

Here's all combined into one command. The source could be both texts or mtexts. 

Updated.

@john.uhden find the example of usage inside there.

[john.uhden]

That's alright. I've got my own.

[ChrisWebster]

@ВeekeeCZ Thanks! But I get an error:

Command: MASKWORDS
Select objects: 1 found
Select objects: bad argument type: lentityp nil :error#0

[ВeekeeCZ · Accepted solution]

Ok, found it and fixed it.

Now you can also select a single word TEXT to convert and add the mask, or MTEXT to unify the formatting with/of the mask.

For next time, always post a dwg with examples of (failing) texts!

BTW the route of using mtext columns that @Sea-Haven mentioned is also worth exploring. The limit is that you can't position each column as would be appropriate according to word length, but you can explode it to words anytime...

[ChrisWebster]

@ВeekeeCZ THAT WORKS AWESOME!

[john.uhden]

Hi there @ВeekeeCZ ,

Programmatically, it seems as though the only way to control the background mask offset factor is via dxf 45.  Yet no matter what value you would like to apply, e.g. (entmod (append ent '((45 . 1.1)))), it wants to stay at an apparent default value of 1.5.  Might you know of any solution for that shortcoming?

[john.uhden]

@ВeekeeCZ ,

Another kind of unique feature is when exploding mtext, consecutive characters  of the same color override, including spaces, are treated as one text string.

Thus perhaps one would want to remove partial color formatting before exploding,  Haven't tested, but this may be true for other types of format overrides.

[ВeekeeCZ]

---

@john.uhden wrote:

Hi there @ВeekeeCZ ,

Programmatically, it seems as though the only way to control the background mask offset factor is via dxf 45.  Yet no matter what value you would like to apply, e.g. (entmod (append ent '((45 . 1.1)))), it wants to stay at an apparent default value of 1.5.  Might you know of any solution for that shortcoming?

---

This seems to be working for both creation and modification. Didn't play with that to see what the minimum setting is.

(entmod (append (entget (car (entsel))) '((90 . 3) (63 . 256) (45 . 1.1) (441 . 0))))

[ВeekeeCZ]

---

@john.uhden wrote:

@ВeekeeCZ ,

Another kind of unique feature is when exploding mtext, consecutive characters  of the same color override, including spaces, are treated as one text string.

Thus perhaps one would want to remove partial color formatting before exploding,  Haven't tested, but this may be true for other types of format overrides.

---

Or instead of complicatedly calculating the coordinates for different words, just color them in different colors and explode it.

[john.uhden]

@Sea-Haven ,

I get it.  Using only one (1) space as a delimiter, you can trim away the remaining spaces of each item in the resulting list.  Is that close?

Now if you are willing to let one space get included in a word (phrase) then you you can use my @str2list which accepts multicharacter delimiters.  F'rinstance...

"West     St. James    Street"

can become

"West"   "St. James"   "Street"

[Kent1Cooper]

---

@Kent1Cooper wrote:

....

.... the bounding box of Mtext "reaches" leftward to encompass leading spaces if present....  So:

1.  divide up the Mtext's content at the spaces, keeping each space as part of the string of the following word;

....

3.  put in individual Mtext objects for each word, individually set to zero defined width, positioning them by their bounding boxes which [after the first] will include the spacing from the previous one;

....

---

I decided to try that approach [adding to that description the forcing of no columns in Mtext because you can't give it zero width otherwise, and the removal of the leading spaces in each word after its position is established], just as an interesting exercise.  And I expanded to accept selection of plain Text.  The result is the attached -- see the comments at the top of the file.

But I found the include-the-leading-spaces bounding boxes must be a little short of actually reflecting the width of the leading spaces, because I got this kind of result:

The green is the original, and the magenta the result of applying the MTBM command to a copy-in-place of it.  [I moved the green original in front with DRAWORDER to get out from behind the result's masking, so the comparison is apparent.]  The first word is exactly under the original, but the spacing between the rest tightens in a little as they go.

I decided to try @ВeekeeCZ 's accepted-solution MaskWords command at Message 28, to see whether it does better at that.  I found that it has better [though not perfect] relative positioning between the separate words overall, but in this case the results are shifted out of place, in both directions:

In some further trials, I found that didn't happen if the source object was at zero rotation, so I wondered whether the issue is rotation-angle-dependent, and sure enough....  Here, the green are the originals and the red are the results of MaskWords applied to a red copy exactly in place [I did not Move the results -- this is where they landed]:

Not only does the position shift get worse with increasing difference from 0° of the rotation angle, but note the irregular spacing in both the 90° and 270° examples [the "a" and "test" are too close together], which for some reason doesn't happen in the 180° example.

My MTBM command still has the same slight shortening of the spacing between words at other rotation angles, but the angle difference has no effect:

Those are from Mtext originals.  From a plain-Text original at 90°, MaskWords had the positional shift and a worse spacing reduction problem; MTBM handles it the same as an Mtext original:

I haven't studied MaskWords in detail to try to figure out what could be causing these shifts and spacing issues with source objects at rotations other than 0° -- I leave that to @ВeekeeCZ to investigate.  I will also investigate MTBM's spacing-tightening issue, to see whether there's a way to get the results more exactly positioned in relation to the source objects.

[john.uhden]

@Kent1Cooper ,

Your usual diligence is greatly appreciated.

I have come to feel that exploding the mtext is the solution to keeping the text entities in the right place.  I've just been hung up on dxf 45 not taking and of course the interruption of work work.  I probably oughta take my C3D work laptop home with me this weekend to cobble together a working command function, regardless of dxf 45.  Though I will be immersed in celebrating my grandson's 2nd birthday on Sunday.

[ВeekeeCZ]

@Kent1Cooper 

what version did you test it in? It's TXT2MTXT that was buggy (sure in 2020) but I believe it was fixed (2022+).