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.

[Kent1Cooper]

---

@ChrisWebster wrote:

.... Have the same look but ....

---

You mean in the same visual arrangement in the drawing, so a sentence and/or a paragraph will still read as the single source Mtext did?  Wow....

There are various routines out there to subdivide text string content into separate strings around whatever delimiting character(s) you want [presumably a space in this case], but I'm having a hard time imagining how the resulting individual-word objects could be positioned for the "same look."

[And I confess to being curious:  what would be the purpose of doing this?]

[pendean]

@ChrisWebster Sort of like when you EXPLODE an MTEXT but the results are each an MTEXT instead of TEXT?

Or are you thinking of some other process ?

[john.uhden]

@pendean ,

And the explosion creates separate lines of text for each line of mtext, not separate words, unless of course there was just one word on each line.  But that's a nightmare if he thinks all the words are going to end up in the same position before being chopped up.  Yeah, of course we could take a hack at it (pun intended), but I can't conceive of the purpose.  Maybe he wants to select certain words to change their color or style, but the mtext editor provides that capability and will adjust the spacing with following words if the change creates a different width.

[Sea-Haven]

My $0.05 is he trying to make columns out of the mtext so using tabs would fix, now where is that post about removing tabs from the other day.

[pendean]

---

@john.uhden wrote:

@pendean ,

And the explosion creates separate lines of text for each line of mtext, not separate words, unless of course there was just one word on each line.  But that's a nightmare if he thinks all the words are going to end up in the same position before being chopped up.  Yeah, of course we could take a hack at it (pun intended), but I can't conceive of the purpose.  Maybe he wants to select certain words to change their color or style, but the mtext editor provides that capability and will adjust the spacing with following words if the change creates a different width.

---

Agreed: the OP will need to chime in to answer these questions and to share their most common example MTEXTs.

[john.uhden]

@Sea-Haven ,

What I got out of the other post is that removing the tabs "\t" is easy but the tab stop definitions are a bit challenging.

[mcweb]

DELETE!

[ChrisWebster]

I have lots of spaced-out mtext objects (street, route, road, highway names) that I want to use background mask on. But I don't want to mask the spaces. I am manually editing them - copy for each word, editing each item, masking. On the left before, right after I manually editing.

 

[Kent1Cooper]

---

@Kent1Cooper wrote:
.... I'm having a hard time imagining how the resulting individual-word objects could be positioned for the "same look." ....

---

[EDIT -- Message 9 arrived while I was writing this, and what it's talking about is less complex in some ways, but most principles could still apply....]

Actually, I'm starting to imagine that it might be possible, at least with some conditions.  The critical thing I'm finding is that the bounding box of Mtext "reaches" leftward to encompass leading spaces if present, in contrast to the fact that [for whatever reason] it does not "reach" rightward to encompass trailing spaces.  So:

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

2.  divide at any hard or soft returns, with some encoding of their presence to cover line breaks that are not just the result of word-wrapping;

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;

4.. watch for when one would overshoot the source Mtext's right-most extent, and if it would, go to the next line.  The line spacing for moving down to the next can be calculated from the source Mtext's entity data.

There's the question of the position of the first word on each line after the first, if its bounding box includes a space that you wouldn't want at the beginning of the line.  It should be possible to determine that a word would overshoot the right side, and if so, to not just go down to a next line, but to first remove the space and re-establish the bounding box.

I think that might not be too hard for Top-Left-justified Mtext at "Exactly" line-spacing style.  If this is all bounding-box-based, it turns out that bounding boxes do not account for taller-than-capitals [in some fonts] characters like | / ( ), which are the things that stretch the line spacing under "At Least" spacing style.  I'm not sure how one could account for that kind of line spacing variation, since how much taller those characters are is buried in the font definition, and not available from something like entity data.  And at the time a new line is started, it wouldn't know whether a taller object might be coming farther along on that same line.

Working from other source-Mtext justifications could be rather complicated, but may be possible.  For right justifications it would presumably involve Moving a whole line's worth of words leftward as each word is added.  Likewise for bottom justifications, Moving whole lines upward as each new line is started, etc.  Non-zero rotations would further complicate things.

Internal formatting such as color and font and size changes would get messed up unless they apply only to a single word, with their coding fully contained between the spaces around that word.  Whether to STRIP all internal formatting first would be a question.

Anyway, something to think about....

[john.uhden]

@ChrisWebster ,

That's a pretty good idea.  Of course you should have labeled the road names with separate pieces of text in the first place.  I don't have it installed but isn't there a TXTEXPLD (sp?)  in Express Tools?

If so, I think you could explode all the mtext labels into text objects (one for each line), then TXTXPLD (sp?) all the text objects into separate words, then convert all the text to mtext and then apply the background masks.  That could probably be all wrapped up into one lisp command, with the only snag of having to select all the candidates.  But grabbing one and applying SelectSimilar might do the job (hopefully they are all on the same layer).

[Sea-Haven]

Hi John TXTEXP. Then yes get each text and convert to mtext with a mask. Using VL Backgroundfill.

[mcwebster]

TXTEXP explodes text and mtext into polylines?

[Sea-Haven]

Was about to respond to John yes goes to far dont use.

[Sea-Haven]

Try this it will not align 100% but should be close enough, uses space as the delimiter between words.

; Take mtext read it as words and add a mtext with box around each word
; By alanH Jan 2024

(defun c:mt-words-box ( / M-Text-mask _csv->lst32 ss obj str lay ht pt rot sty lst val)
 
(defun M-Text-mask (pt str)
(entmakex (list
(cons 0 "MTEXT")         
(cons 100 "AcDbEntity")
(cons 100 "AcDbMText")
(cons 10 pt)
(cons 8 lay)
(cons 1 str)
(cons 7 sty)
(cons 90 1) 
(cons 63 1) ; colour
(cons 45 1.2) ; gap
(cons 441 0)
))
)

; thanks to Lee-mac for the csv-lst

(defun _csv->lst32 ( str / pos )
	(if (setq pos (vl-string-position 32 str))
		(cons (substr str 1 pos) (_csv->lst32 (substr str (+ pos 2))))
		(list str)
    )
)

(prompt "select mtext to have mask ")
(setq ss (ssget '((0 . "MTEXT"))))

(if (= ss nil)
(progn (Alert "No Mtext selected \n\n Will exit try again")(exit))
)

(repeat (setq x (sslength ss))
  (setq obj (vlax-ename->vla-object (ssname ss (setq x (1- x)))))

  (setq str (vlax-get obj 'textstring))
  (setq lay (vlax-get obj 'layer))
  (setq pt (vlax-get obj 'insertionpoint))
  (setq ht (vlax-get obj 'Height))
  (setq rot (vlax-get obj 'rotation))
  (setq sty (vlax-get obj 'stylename))
  
  (setq lst ())
  (setq lst (_csv->lst32 str))

  (foreach val lst
    (M-Text-mask pt val)
    (setq len (* ht (+ 1 (strlen val))))
    (setq pt (polar pt rot len))
  )
)

(command "erase" ss "")

(princ)
)

[john.uhden]

@Sea-Haven & @ChrisWebster ,

I've got the fist part working; no explosions.  The plan is to dissect the parts and put the non-blank pieces pretty much where they were based on the angle of the mtext and length of the spaces between.

[ВeekeeCZ]

Have you tried this Lee's function?

http://www.lee-mac.com/texttowords.html

It works only on TEXTs... but try the workflow if you get satisfying results. If so, we could wrap it into a single command.

EXPLODE the MTEXT, apply the routine, and convert it back to MTEXT using TXT2MTXT (mind the setting).

[ChrisWebster]

Well, I really would like to try that, but Lee Mac's website is down. Do you have the code on another site or send it locally? 

[ВeekeeCZ]

Ohh, that's unfortunate. Anyways, here you go.

[pendean]

---

@ChrisWebster wrote:

Well, I really would like to try that, but Lee Mac's website is down. Do you have the code on another site or send it locally? 

---

Seems to be working fine 

http://www.lee-mac.com/texttowords.html