minimum allowed text height in lisp

Anonymous · ‎09-16-2015

http://forums.autodesk.com/t5/autocad-2013-2014-2015-2016/minimum-allowed-text-height-in-lisp/td-p/5...

Hello. I've posted this in the general AutoCAD forum, and in searching through, I found others saying such questions should be posted in this forum-- which I was not aware of.

In one of my lisps, previous programmers had set the text height to 0.006. As a result, because of the type of work we're doing, we need to scale it down after we're finished using the lisp.

Is there a minimum height allowed in AutoCAD for using lisps?

I.e., can I reduce the height to 0.002, 0.003, or something smaller than 0.006?

I've changed it to 0.002, but what that's leaving the value at the 0.006. So, even if I input 0.003, my final height is 0.009, not 0.003.

(if h
    (progn
       (while (< h 0.002)
          (alert msg5)
          (initget (+ 2 4))
          (setq h (getreal msg4))
          (if (null h)
             (setq h 0.002)
          )
       )
       (setq scf (/ h 0.002))
    )
    (setq scf 1)
 )

and yes, I've reloaded the lisp each time I make a new change.

I then did some looking around, and noted that another poster had been told that they had to set their textsize to 0.0 in their textstyle settings, otherwise, that would restrict their mimimum size to THAT setting.

So, I went into textsize and set mine to 0.0000001, because it would not accept a 0.0 setting.

Your helps would be appreciated.

TYIA.

Anonymous · ‎09-16-2015

As I further consider my issue, I'm now wondering if I don't have another issue entirely, or as well as, the first-- that I'd posted above.

When we use this lisp, we're entering numeric values.

Eg., 12345

It then asks for the height, location to drop/place, and layer to be placed on.

The text placed is block-lettering. It's not standard lettering, like what you're seeing here.

In looking through the character map in windows, the closest I'm seeing is something like the Castellar, Fixedsys, Impact fonts.

It's hollow, block letters/numbers, as outlines. LIKE, but not an exact match to Swis721 BdCnOul BT font on the character map.

We do have a dwg file which has all of the letters, numbers, and a hyphen, so we've believed-- up until this morning-- that the lisp routine was extracting the numbers out of the dwg file of the same name.

I just checked to see if typing letters would allow it to input. It does not.

It is calling to an ascii library of some kind, but I'm not able to identify that library.

(setq char (substr txt a 1))   
          (setq asciicod (ascii char))
          (setq blockname (strcat "char" (itoa asciicod)))

This lisp routine only allows for the input of numbers.

I'm attaching a screen shot of the numbers which are output by the lisp routine.

Kent1Cooper · ‎09-16-2015

@Anonymous wrote:

....

I then did some looking around, and noted that another poster had been told that they had to set their textsize to 0.0 in their textstyle settings, otherwise, that would restrict their mimimum size to THAT setting.

So, I went into textsize and set mine to 0.0000001, because it would not accept a 0.0 setting.

....

Don't do that with the TEXTSIZE System Variable. Call up the STYLE command, and in the definition for the appropriate Text Style, make sure the height is set to 0 [which will be accepted there].

Kent Cooper, AIA

Anonymous · ‎09-16-2015

awesome.

Not the complete solution, but it gets me closer.

Thank you. It allowed me to bring in the swis712 xxxx text as well.

It appears that to do the lettering, I'll need to create my own version of the blocked letters.

As for the height issue, it's still not allowing me to set it at 0.002. When I select the 0.002, it sets it at 0.006.

Any ideas?

Again-- TYIA, and for the styles answer. 🙂

Kent1Cooper · ‎09-16-2015

@Anonymous wrote:

....

We do have a dwg file which has all of the letters, numbers, and a hyphen, so we've believed-- up until this morning-- that the lisp routine was extracting the numbers out of the dwg file of the same name.

I just checked to see if typing letters would allow it to input. It does not.

It is calling to an ascii library of some kind, but I'm not able to identify that library.
(setq char (substr txt a 1))   
          (setq asciicod (ascii char))
          (setq blockname (strcat "char" (itoa asciicod)))
.....

It looks like it's not using Text at all, but Inserting Blocks of the numerical characters. It's easy enough to find out -- open that drawing that has all of them, or get into any drawing that has some in it already, and pick on one to see what kind of object it is. If they're Blocks, neither the TEXTSTYLE System Variable nor the defined height of any particular Text Style will be relevant.

The "library" aspect seems to be a group of Blocks, which are named with the ASCII codes for the characters [e.g. for a 4, it would be a Block called "52"]. It may be that there are no such Blocks defined for any characters other than numerical ones and the hyphen. Wherever the 'txt' string variable is coming from, it's only finding the ASCII code for the first character in that string, but maybe later it's lopping that off and looking at the next one. If that reference drawing does contain all characters, seeing more of the code, and how it's going about Inserting Blocks, might reveal whether it could be made to allow letters or other punctuation. Maybe they're all in that drawing, but not all in some findable folder as separate drawing files, as the Insert command would want.

Kent Cooper, AIA

Kent1Cooper · ‎09-16-2015

@Anonymous wrote:

....

As for the height issue, it's still not allowing me to set it at 0.002. When I select the 0.002, it sets it at 0.006.

Any ideas?

....

If it's using a TEXT command to make Text, and it's coming out that way, it sounds like the particular Style still has a fixed/defined Height of 0.006, which will override whatever the current TEXTSIZE setting is. But I would expect you to get some other kinds of errors, because the Text command won't prompt for the height if the current Style has a fixed one. If it used (entmake) instead, it could make it any height, regardless of the Style's defined height. More of the code would be helpful.

Kent Cooper, AIA

Anonymous · ‎09-16-2015

Hi Kent.

We do have a set of dwg files, where the file name is "char xx" where xx is the character's number, from ascii.

When I selected the text in there, it's just a poly line.

I've done so little with blocks. Or, perhaps, more accurately, it's been years since I've used blocks, and had vaguely remembered that the original attributes are lost, and the item imported/inserted as a block is defined as a block, in the destination drawing.

So, I guess my next question would be--

is there code which would be used, that would allow the inserted block item to be converted to a polyline?

(setq lay (getstring msg3))
    (setq ss (ssget "x" '((0 . "INSERT") (8 . "PLTXT"))))
    (setq nrelem (sslength ss))
    (setq poz 0)    
    (while (/= poz nrelem)
       (setq b (ssname ss poz))   
       (command "_EXPLODE" b)
       (setq polyb (entlast))

There is this code near the bottom of the lisp routine.

TYIA.

Kent1Cooper · ‎09-16-2015

@Anonymous wrote:

....

We do have a set of dwg files, where the file name is "char xx" where xx is the character's number, from ascii.

When I selected the text in there, it's just a poly line.

....

is there code which would be used, that would allow the inserted block item to be converted to a polyline?
....
    (setq ss (ssget "x" '((0 . "INSERT") (8 . "PLTXT"))))
    (setq nrelem (sslength ss))
    (setq poz 0)    
    (while (/= poz nrelem)
       (setq b (ssname ss poz))   
       (command "_EXPLODE" b)
....

That looks like it's Exploding all Blocks on the PLTXT Layer [the 8 is for the Layer-name entry], which will convert them to Polylines if that's what they are in their separate drawing files. If they're getting into the drawing with an Insert command, you could also accomplish the same by using an asterisk before the Block name, which will Insert it already Exploded, so you don't need to do it later. Perhaps something like:

(command "_.insert" (strcat "*" blockname) .... ;; but give it only one scale factor [it won't ask for both X and Y]

Or, include it in the setting of the 'blockname' variable in the first place, and not in the Insert command, e.g. [from an earlier message]:

....

(setq char (substr txt a 1))
(setq asciicod (ascii char))
(setq blockname (strcat "*char" (itoa asciicod))) ;; but still give it only one scale factor where the Insert happens

....

But if you'll have multiples of the same character, I'd recommend keeping them as Blocks if you can, which will reduce the drawing file size.

Kent Cooper, AIA

Anonymous · ‎09-16-2015

Ok.

This is great.

Thank you.

Next item about this......

The existing polyline letters/numbers in their original "char xx.dwg" files are in fact, 0.006 units tall.

I reduced one to a 0.004, and ran the lisp. It still came in at a 0.006, even with the modified code

(while (< h 0.002)             
          (alert msg5)              
          (initget (+ 2 4))          
          (setq h (getreal msg4))    
          (if (null h)               
             (setq h 0.002)
           )

What would I do to ensure that the preferred size, which is less than 0.006, be the final output?

TYIA...

Kent1Cooper · ‎09-16-2015

Might you have run the Lisp in a drawing that already contained that Block name with its earlier definition? If you Insert a Block that's already defined in the drawing, it won't reach out to an altered drawing file origin to update the definition unless you force it to, in a non-dialog-box way, using the "blockname=filename" format for the Block name, and answering Yes to the question of whether to redefine it. If it works right in a new drawing, in which it doesn't already have a Block definition by that name, that may be the issue.

Personally, I would define the Block with a "native" [unscaled] height of 1 drawing unit, and then the Y scale factor of the insertion would always be its end-result height. The code for the actual Insertion part, as well as whatever sets any variables that are used in that, should reveal what's happening to make it not the size you want.

Kent Cooper, AIA

Anonymous · ‎09-17-2015

Good morning Kent.

Thank you for your response last evening.

@Kent1Cooper wrote:
Might you have run the Lisp in a drawing that already contained that Block name with its earlier definition? If you Insert a Block that's already defined in the drawing, it won't reach out to an altered drawing file origin to update the definition unless you force it to, in a non-dialog-box way, using the "blockname=filename" format for the Block name, and answering Yes to the question of whether to redefine it. If it works right in a new drawing, in which it doesn't already have a Block definition by that name, that may be the issue.

Personally, I would define the Block with a "native" [unscaled] height of 1 drawing unit, and then the Y scale factor of the insertion would always be its end-result height. The code for the actual Insertion part, as well as whatever sets any variables that are used in that, should reveal what's happening to make it not the size you want.

Ok.

I've taken one of the source files, and scaled the number to one drawing unit.

When I input the desired value of 0.006 (even though it's already set in the input dialog), the lisp sets it at 0.006. Any input I select.... 0.007, 0.010, etc.... the height is correctly set.

When I then change the code to do 0.002, and after saving, and reloading the lisp, inputing 0.002, the number height is set to 0.006.

If I then select 0.003, the height is set to 0.009.

Yet, if I select the height as 0.010, the height is set to 0.030.

The code is:

(setq msg1 "\nType the text: "
         msg2 "\nStart point: "
         msg3 "\nType the text layer name: "
         msg4 "\Text height <0.002\">: "
         msg5 "Invalid value\nText height must be > 0.002\""
   )

.............................................

(setq txt (getstring 1 msg1))
 (initget (+ 2 4))      ; 2 = no zero, 4 = no negative
 (setq h (getreal msg4))
 (if h
    (progn
       (while (< h 0.002)
          (alert msg5)
          (initget (+ 2 4))
          (setq h (getreal msg4))
          (if (null h)
             (setq h 0.002)
          )
       )
       (setq scf (/ h 0.002))
    )
    (setq scf 1)
 )

it would appear that the height of the final output is determined by the

setq scf (/ h 0.002)

Thus, if I input 0.003, the code reads--

0.003/0.002 which = 1.5, making the output 1.5 x the baseheight, making it a 0.009 = (1.5 x 0.006)

If I input 0.010, the code reads--

0.010/0.002 which = 5, making the output 5 times the baseheight, making it 0.030 = (5 x 0.006)

if I input 0.007, the code reads--

0.007/0.002 which = 3.5, making the output 3.5 times the baseheight, making it 0.021 = (3.5 x 0.006)

How in the world can I obtain better control on this?

Again, I've set the number, from which the block is pulled, to a drawing unit height of one (1).

Again, thank you, in advance for your time, and help......

Anonymous · ‎09-17-2015

Ok.

In investigating this further, I've found something interesting out.

If I comment out the line-- (setq (/ h 0.006))

and then reload, and run the lisp, I get the following.

if I use the default required input (0.006), the output is a 0.006 sized/height number.
If however I input ANY other number, the routine does nothing, and just stops.
Putting in any other number includes entering 0.006.
No errors are thrown, it just does nothing.

It appears to me that (setq scf ( / h 0.006)) is setting the letter height, though I'm not seeing where.

(init_values) 
 (setq txt (getstring 1 msg1))
 (initget (+ 2 4))      ; 2 = no zero, 4 = no negative
 (setq h (getreal msg4))
 (if h
    (progn
       (while (< h 0.006)
          (alert msg5)
          (initget (+ 2 4))
          (setq h (getreal msg4))
          (if (null h)
             (setq h 0.006)
          )
       )
       (setq scf (/ h 0.006))
    )
    (setq scf 1)
 )
 (initget 1)
 (setq pins (getpoint msg2))
 (setq n (strlen txt))
 (setq a 1)
 (setq xincr (* scf 0.0048)) 
 (while (<= a n)
    (if (= (substr txt a 1) " ")
       (progn
          (setq px (+ (car pins) (* xincr 0.5)))
          (setq pzy (reverse (cdr pins)))
          (setq pins (append pzy (list px)))
          (setq pins (reverse pins))
          (setq a (+ a 1))
       )
       (progn
          (setq char (substr txt a 1))    
          (setq asciicod (ascii char))
          (setq blockname (strcat "char" (itoa asciicod)))
;;LCA - COMMENT: The LAYER command has new options.
          (command "_LAYER" "M" "PLTXT" "")
          (command "_INSERT" blockname pins scf "" "")
          (setq a (+ a 1))
          (setq px (+ (car pins) xincr))
          (setq pzy (reverse (cdr pins)))
          (setq pins (append pzy (list px)))
          (setq pins (reverse pins))
       )
    )
 )
    (setq lay (getstring msg3))
    (setq ss (ssget "x" '((0 . "INSERT") (8 . "PLTXT"))))
    (setq nrelem (sslength ss))
    (setq poz 0)    
    (while (/= poz nrelem)
       (setq b (ssname ss poz))   
       (command "_EXPLODE" b)
       (setq polyb (entlast))
;;LCA - COMMENT: The CHANGE command has new options.
       (command "_CHANGE" polyb "" "P" "LA" lay "")
       (setq poz (1+ poz))
    )
 (unload_values)
 (princ)

Kent1Cooper · ‎09-17-2015

Is (init_values) where you're putting in numbers? Does the number you input end up in a variable? What's it called, and how does it fit into the code you've posted?

I'm trying to figure out why you don't just skip the scf variable entirely, and use h in its place, but I may not be understanding the relationship correctly, and/or maybe (init_values) would reveal something about that.

[I would use (getdist) instead of (getreal) in (setq)ing h, so you can pick on-screen or enter a fraction, if you want, neither of which (getreal) will accept.]

There are several things that can be simplified, if I'm interpreting things correctly:

This stretch:
(setq px (+ (car pins) xincr))
(setq pzy (reverse (cdr pins)))
(setq pins (append pzy (list px)))
(setq pins (reverse pins))
can be replaced by just:
(setq pins (polar pins 0 xincr))
or if you want to see more of the pieces involved:
(setq pins (cons (+ (car pins) xincr) (cdr pins)))

I believe these parts:
(command "_INSERT" blockname pins scf "" "")
together with the later:
(setq ss (ssget "x" '((0 . "INSERT") (8 . "PLTXT"))))
(setq nrelem (sslength ss))
(setq poz 0)
(while (/= poz nrelem)
(setq b (ssname ss poz))
(command "_EXPLODE" b)
(setq polyb (entlast))
(command "_CHANGE" polyb "" "P" "LA" lay "")
(setq poz (1+ poz))
)
can be replaced by:
(command
"_.insert" (strcat "*" blockname) pins scf "" ; asterisk prefix inserts pre-exploded; one scale factor
"_.chprop" (entlast) "" "_layer" lay ""
)

Kent Cooper, AIA

Community

minimum allowed text height in lisp

minimum allowed text height in lisp

minimum allowed text height in lisp