Hello,
when i explode a text with TXTEXP i obtain a text of polylines. But this text of polylines has lines inside letters or numbers... I want select all of these lines (the lines inside the text) to delete them. Or select a border of the text to move it.
I don't want select the lines one by one... how can i do?
Thanks
This will help you a lot, not 100% as other app but you can try it after txtexp.
http://www.lee-mac.com/outlineobjects.html
Unfortunately, a routine in AutoLisp that could do that automatically would be a real challenge. It would need to be able to identify which segments of the resulting Polylines are the crossing-inside-the-characters ones. They're not always the first or last segment, or the longest or shortest, or some such criterion that would give you something to work with easily [and besides, some contain more than one such segment].
But I can imagine a possible way, if you don't mind the Polylines being Exploded. [The cleaned-up outlines could presumably be re-assembled back into Polylines from the remaining Lines at the end.] Is that of any interest?
Draw a closed rectangle around the text, change to a layer not used by the text, use bpoly and select inside the rectangle and inside any closed letters, lock the layer the bploy is on, erase the old exploded text, unlock the layer.
GrantsPirate
Piping and Mech. Designer
Always save a copy of the drawing before trying anything suggested here.
----------------------------------------------------------------------------
If something I wrote can be interpreted two ways, and one of the ways makes you sad or angry, I meant the other one.
@Kent1Cooper wrote:
.... But I can imagine a possible way, if you don't mind the Polylines being Exploded. ....
Here's the concept [without putting the Lines back together, or any of the usual features, yet], but it doesn't work correctly everywhere:
;; Use immediately after TXTEXP when "Previous" selection will be its results.
(defun C:TECU ; = Text Explode Clean-Up ;;;; NOT yet working right -- partially....
(/ plSS plList pl1e pl1o pl2o ints insiders endA endB item mid)
(setq
plSS (ssget "_P")
; the 2DPolylines resulting from TXTEXP, if done immediately after
plList (mapcar 'cadr (ssnamex plSS)); as list of entity names
); setq
(repeat (1- (sslength plSS))
(setq
pl1e (car plList); first as entity name
pl1o (vlax-ename->vla-object pl1e); as VLA object
plList (cdr plList); rest of the list [1st removed]
); setq
(repeat (setq n (length plList))
(setq
pl2o (vlax-ename->vla-object (nth (setq n (1- n)) plList))
ints (vlax-invoke pl1o 'IntersectWith pl2o acExtendNone)
); setq
(if ints (setq insiders (cons ints insiders)))
); repeat
(command "_.explode" pl1e); [1 at a time avoids messing with QAFLAGS]
); repeat
(command "_.explode" (car plList)); remaining one at end
(foreach item insiders
(while item ; [can be 2 points, or 4, possibly more?]
(setq
endA (list (car item) (cadr item) (caddr item)); 1st 3
item (cdddr item); take 3 off
endB (list (car item) (cadr item) (caddr item)); 1st 3 of remaining
item (cdddr item); take those 3 off [returns nil after last point]
mid (mapcar '/ (mapcar '+ endA endB) '(2 2 2)); halfway between
); setq
(command "_.erase" mid "" "_.erase" mid ""); two Lines there
); while
); foreach
); defun
The problem is that when a pair of resulting 2DPolylines connects along more than one through-the-inside line, you can't count on the first two intersection points being the ends of one of those lines -- they can be an end of one of them and an end of another, which can give this kind of result:
The colored ones on top are the results of TXTEXP, with the separate Polylines color-differentiated, so you can see where their coinciding edges are. The white bottom ones are the result of running the TECU command on that.
It got the C right because there are no pairs of Polylines that intersect in more than two locations. In the B, there are [the red one intersects both the yellow and green ones along more than one edge each], but their intersection points came out with those defining the same internal line being adjacent in all cases. But the A failed, because they didn't come out that way. The midpoint locations it tried to use for Erasing are the cyan Points between locations at the ends of the magenta dashed lines. So not only did it miss the Lines intended, but it also Erased one [near the left Point] that wasn't internal and should have been kept.
It also has the issue of Erase selection potentially finding the wrong thing even at the right place [which is affected by Zoom level]. I tried Erasing by selecting at midpoints, because I had trouble getting it to find the internal Lines with (ssget) and the endpoints, so as to use (entdel) instead -- probably about the differences many decimal places down in real number values, but I'll experiment further. If that can be overcome, there's still the problem of its having endpoints not paired right in the (intersectwith) results. I don't think it's reliable to check proximities -- the two that are closest together, though they would define one of the internal Lines in the capital A here, surely won't always do so.
Anyway, it's a start, perhaps....
