Multiple Texts to Mtext at different Locations
@saqib_tipa wrote:
... I want to make separate groups of Mtexts if they are near to each other at 5 unit. ....
So if the insertion points are the basis of the measurement of whether things are "near to each other," and if a given Text object is the reference location, must all Text objects to be combined with it into Mtext have their insertion points within 5 units of that reference? Or if a second one is within 5 units of the first, and a third is within 5 units of the second but not within 5 units of the first, should that third one be included? And a fourth? Etc.
@saqib_tipa wrote:
.... 4 of them are near to each other and have 5 or less units distance between them then they should be combined into one Mtext ....
So in this location:
let's say the routine starts off considering the L: Text object, and builds a crossing-window selection box [the dotted white square] of 5-unit "radius" around its insertion point. That will find the D : * and S: Text objects, but will not find the (RMS object. So the routine would need to take objects that it finds, and do the same kind of search around each of them. When it gets to searching near the S: object, it will finally find the (RMS object. Once it has done the same search around all objects found, then it will have a set to convert to Mtext.
[If it happened to start its search around the S: object, it would have found all of them on the first pass, but there's no guaranteeing which one in a group it will start with, unless the groups are always formatted exactly like these, so the initial selection of things to search around can be limited to only Text starting with S: .]
And that assumes there won't ever be things in one group that are close enough to another group to get caught in its search web.
Does that sound right?
[* The D-plus-colon combination gets turned by the website into an emoticon, which is why I had to add the space betwen them.]
May be useful can then offset the 5 and use ssget "F"
; By Anonymous 2001
(defun C:BoxText (/ tbox)
(setq Tbox (acet-geom-textbox (entget (car (entsel))) 0))
(command ".rectangle" (nth 0 Tbox) (nth 2 Tbox))
(princ)
);defun
Then make say 2 into new mtext get new textbox and keep going, need to take into account text on angle, closer to the correct outline than bounding box.
No code at this stage.
@saqib_tipa wrote:
.... or you can make radius bigger than 5 ....
Something like this? [minimally tested]:
(defun C:T2MG ; = Text {to} Mtext in Groups
(/ ss n txt ble tt)
(if (setq ss (ssget '((0 . "TEXT") (8 . "PIPE"))))
(repeat (setq n (sslength ss))
(setq txt (ssname ss (setq n (1- n))))
(if (entget txt); still exists [not absorbed into Mtext yet]?
(progn ; then
(setq ble (cdr (assoc 10 (entget txt)))) ; = baseline left end
(if
(> ; more nearby?
(sslength
(setq tt
(ssget "_C" (mapcar '- ble '(10 10)) (mapcar '+ ble '(10 10))
'((0 . "TEXT") (8 . "PIPE"))
); ssget
); setq
); sslength
1
); >
(command "_.txt2mtxt" tt ""); then
); if [multiple text in area]
); progn
); if [txt still exists]
); repeat
); if [text selection]
(prin1)
); defun
I used the 10-code entry [left end of baseline] as the basis point, because it's always the same regardless of justification. Probably the insertion point would do, too [I didn't experiment].
For some reason I can't figure out, some of them come out with appropriate-looking line spacings [left], and some with extra spacing between some lines [right] (which is not from Enters for blank lines):
It could be related to the rotation angle, and the particulars of the staggering of insertion points, and something about how TXT2MTXT considers relative positions, because there's one that ends up really wacky:
and it's the only one at a rotation anything like that. [See EDIT below.] Those like the right one in my first image also have the D:S:L: order rather than the S:D:L: order of the originals. Those are all under the sort-top-down mode in TXT2MTXT. It seems not to happen if in the select-order-of-objects mode when done manually, but if that's the setting ahead of time, under this selection-set approach yours all get reversed in order. It may be possible to feed them into the command in the right sequence, but I think it would be quite a challenge to work out.
I don't understand why those that look right have the extra line spacing between the first two lines, either, but at least it gives a nicer result than if the line spacings were equal.
[EDIT: It's the combination of rotation in relation to stagger of insertion points. That result is, in fact, in order of the raw never-mind-the-rotation Y components of their insertion points, from top to bottom, under sort-top-down mode. But I still don't get the irregularity of the line spacing.]
Thank you for the code. It works nicely.
For some reason I can't figure out, some of them come out with appropriate-looking line spacings [left], and some with extra spacing between some lines [right] (which is not from Enters for blank lines):
There is no extra Gap in my Mtext, maybe I applied manually these settings of command TXT2MTXT to one group of Texts before Lisp command.
And for this I figured out a small solution, in Find command I searched and selected "RMS" and move them vertically up 2 units to make sure all RMS are in first line, and they can be moved down after Lisp.
In future if you could find a solution to handle these things It will be more helpful.
But still, this is very useful Lisp that works nicely.
Thank you so much for your time code.
