Text Spacing Lisp Routine
This may be slightly different from what you're asking, but you may be able to use OneMtext.lsp with its 1MT2 command, available >here<. It assembles both Text and Mtext objects into [as the file name and the 1 at the beginning of the command name imply] One Mtext object. It contains other commands, also -- the 2 at the end of the command name I'm suggesting means it puts 2 Enters between the content of each selected object, so that there's an empty line between what came from each original object. It uses the Mtext-box width of the first selected one, so later-selected ones can end up with their line-break locations different from their original configuration.
Differences from your description: It doesn't space the objects as separate ones, but combines them into one, which is how it gets them aligned. And you don't get to specify the "reasonable, uniform distance apart," but it's the result of the line spacing of the font involved, and whether the first Mtext object is set for "At least" or "Exactly" line spacing. I hope that ends up being "reasonable" enough for you.
Unlike the TXT2MTXT command, it accepts both Text and already-Mtext objects, and the order they combine in depends on the order of selection, not their relative original positions.
[Other commands defined in the file: The 1MT1 command puts 1 Enter between, that is, starts a new paragraph for the content of each selected object, but without an empty line between. The 1MT0 command puts just a space between, rather than any Enter(s), so that the combined content "flows" through in one continuous paragraph.]
Here's what 1MT2 does:
@eoconnor95662 wrote:
This will most likely fit the bill, however could you make it so I can drag and select MTEXT boxes rather than individually click on for desired merging? I have a rather large data set.
I made that routine for the purpose of combining a lot of specification-like notes that were separate Mtext and Text objects in multiple columns of them, and I needed something that not only accepted Mtext but also did not work positionally as TXT2MTXT does, because of this kind of [simplified example] situation:
That TXT2MTXT result in the middle [no matter how the Text objects are selected] has a text-string content [without the word-wrapping] of:
"TEXT 1 TEXT 5 TEXT 2 TEXT 6 TEXT 3 TEXT 7 TEXT 4 TEXT 8"
which is completely not what I needed. It's the columns situation that causes it, since it's position-based. I needed one object with the string contents in non-positionally-based order, as on the right, which is why it's set up to use order of selection.
It could be altered to use some other order, but figuring out how to work that could be a challenge -- what kind(s) of circumstances would you have? Would you ever have anything like my multiple columns? If not, would you always want things in positional order, but just straightened out / spaced this way? [If they're sort of in the ballpart, they could be sorted by, for example, the Y coordinates of their insertion points, but would sorting by X coordinates ever be more appropriate?] How far out of alignment might things be? If you pick things by window, the order in the selection is related to drawing order, which may have no relation to the order you want the results in. Are you willing to at least be restricted to Fence-based selection, so that the result will have an order that you can control, but without your needing to pick things one at a time? If so, you would need to be careful to make your selection Fence cross some character in each object, and not pass through a space between, where it won't find that object.
@eoconnor95662 wrote:
...they are already aligned to a side (X-position) but merely need to be condensed (Y-position). It will always be just 1 large column. Alignment spacing should be just far apart enough to read the separate Mtexts.
They are ordered from top to bottom and need to be kept as such.
Also there is blocks referenced by the text right next to it, I assume moving those also are more difficult ....
That would be possible in two general ways: 1) combination into one Mtext with blank lines between, as in the 1MT... commands, and 2) positioning of each independently based on its bounding box, with whatever size space between them you like [such as, for example, 1-1/2 times the text height].
Establishing the order of them is the challenge. If you don't mind being restricted to Fence selection running down the column, the order in such a selection set follows the Fence, which makes it fairly easy. If you want more flexibility in selection [windowing, lassoing, individual picks, removing/adding, etc.], a routine could determine relative position from sorting by the Y coordinates of insertion points.
If there's a single Block associated with each Mtext object, and no Mtext object does not have a Block associated with it, I can sort of imagine a way to include positioning of those. It would mean [as I'm imagining doing it] keeping the Mtext objects separate. And it would depend in part on the width of the Mtext objects. Would those vary? I ask because the bounding box of Mtext, that would used to determine where in the X direction to put the Blocks, is the width of the Mtext "envelope" box, not the width of the actual content. So if the "envelope" of any may be a lot wider than what's in them, and a lot wider than the others, the Blocks could land farther away from the column of Mtext than you want.
