Mtext problem
That would be because the original uses hard returns to make new lines, not word wrapping based on the defined Width of its Mtext box [and may not even have any Width defined], whereas the result of TXT2MTXT combining decides on a box width from the selected objects, and the new breakdown into lines is the result of mere word wrapping resulting from that width -- no, the carriage returns are not saved anywhere.
One thing you can do is to use the fact that the results from an EXPLODE command become the "Previous" selection set. Immediately after EXPLODE, try this:
(setq
texts (ssget "_P"); the resulting pieces, in a selection set, in order from top to bottom
A (cdr (assoc 1 (entget (ssname texts 0))))
B (cdr (assoc 1 (entget (ssname texts 1))))
C (cdr (assoc 1 (entget (ssname texts 2))))
); setq
Combine them with TXT2MTXT after doing that, if you still need them combined.
That assumes three and only three lines in the source. If there might sometimes be different numbers of lines, that can also be accounted for with a little more sophistication in the code.
EDIT:
Another good reason to do it that way [i.e. before recombining if needed] is that depending on the relative lengths of different lines in the hard-returned version, the breakdown between lines can come out differently in the TXT2MTXTed combination than it was in the original:
I think TXT2MTXT determines the resulting Mtext box width from the longest line among those selected, and since it strings the entire combined content into one line without returns, leaving the line breaks to word wrapping, the shorter pieces in the upper lines in this example get shifted because more of them fit in that width.
@zph wrote:
.... However, your solution isn't an option.
.... I will need to incorporate additional string recognition ....
I'm curious as to why it's not an option. What are the circumstances? Can they be tweaked in some way to incorporate that approach, by doing something or other in a slightly different order, or something? I can't suggest anything specific without more detail about where this is all coming from, but you might be surprised -- there could be a way around it.
If it really isn't an option, that additional string recognition would be comparatively simple if you could simply break the resulting string into substrings around spaces [there are several routines around here that will do that]. It will be much trickier if something you want saved as a single string includes a space within it, as one does in your example. It may be possible if you can define only limited possible circumstances, such as that any single-letter "word" in the string should always be combined with the word before it, but that depends on the possible configurations of the pieces you will encounter. Those are some of the reasons why the save-the-variables-before-recombining approach would be so much simpler, if there's some way to make it possible.
Avoiding the problem by code.
Have you tried to disable the "Create word-wrap MText" option in the "TXT2MTXT" options?
That doesn't really tell me enough to understand why it can't pull the string content out of the pieces after Exploding and before re-assembling, as opposed to [for example, if it re-assembles the no-format pieces using the don't-word-wrap option in TXT2MTXT] subdividing around \\P elements, or something.
@zph wrote:
This routine will only read the Mtext entities, not modify them.
It will need to be able to effectively handle unformatted and formatted Mtext values.
....
So you may have some that have multiple lines via hard returns, and some that have them as a result of word wrapping, and some that might have things like font and/or color and/or size and/or other formatting within them, and what you want is to extract each line without formatting and save it into a text-string variable.
You can dump all internal formatting with a routine called StripMtext, links for which you can find with a Search. That could presumably be modified to take the color/font/etc. formatting out of just the string content pulled from one, without modifying the Mtext object itself. Then there are routines that will break a string apart around any kind of delimiter you want to specify, in this case presumably the \\P for those that use hard returns, and you could thereby get the unformatted content of each line. But that won't get you the breakdown between lines when that comes from word wrapping.
I suspect the easiest thing to do would be to have a routine make a copy of the Mtext object, Explode the copy and put the contents into variables as in Post 2, and then get rid of the temporary pieces from the copy. That would handle the breakdown into lines correctly no matter how it's arrived at, and eliminate all formatting. Does that sound viable?
