Lisp Routine to change Text Style of Objects

[jamesloy22]

I am looking for a lisp routine that takes a text objects of a particular text style and changes the text style to another defined text style. However, the big challenge is that I want the text size (height) and font name of the object to remain that of the orginial font style, not that of the text style we are converting to. This would mean that after you run the lisp routine, the visual look of the text would look exactly the same, just the text style name would have changed. 

Thanks in advanced.

[Kent1Cooper]

I am trying to picture a reason that you would want such a result, but....

You could retain the height of a Text object even if the new Style has a different fixed height defined.  What you describe regarding the font, however, is not possible, as far as I know, using ordinary Text.  But it is possible with Mtext, if it contains an internal font override on all of its content [or even more than one font override on different parts of it].  You can change the Style assigned to the "outer" Mtext object, and the "inner" override(s) will remain in effect.

[jamesloy22]

I want to be able to have text styles (that my drafters are used to using) and then convert all the text to a different named style at the end of the project when we submit to another company who wants to see their style.

If you use mtext, could you provide a starting place for what a lisp routine would look like?

[Kent1Cooper]

---

@jamesloy22 wrote:

I want to be able to have text styles (that my drafters are used to using) and then convert all the text to a different named style at the end of the project when we submit to another company who wants to see their style.

If you use mtext, could you provide a starting place for what a lisp routine would look like?

---

Wow...  They certainly won't "see their style" if it doesn't have the same font as their style -- they would only "see" it if they picked on a piece of Mtext and looked at the name of the Style that is [only nominally] assigned to it.

But to answer your question:  Assuming your drafters would be putting Mtext in without internally selecting all of its content as they go to assign an override font to it, you would need such a routine to apply that to all Mtext objects, not by changing their assigned Style [that's easy, and that's what you'd eventually do to nominally give it the other company's Style], but internally within their textual content.  And you would have to convert all ordinary Text objects into Mtext to do the same to them.

Here are the relevant entries from the entity data for a piece of Mtext without a font override:

(1 . "This is a test.") (7 . "NOTESTD")

The code-1 entry is for the textual content, and the 7 is the entry for the Style [NOTESTD is just a Style name of ours, which uses the ROMANS font].

After grabbing all the content and assigning it a font of Swiss721 BT [one that comes with AutoCAD and looks like Helvetica (which is the Latin word for "Swiss"), but it could be anything], the same entries look like this:

(1 . "{\\fSwis721 BT|b0|i0|c0|p34;This is a test.}") (7 . "NOTESTD")

The Style name remains the same, but the content does change in appearance to the override font -- all that green stuff is what accomplishes that override.

It wouldn't be too complicated to add the prefix gobbledegook, using the font name you want, and the suffix brace at the end, around the content of all Mtext objects.  But there are complications:

Say one says 3/4" conduit with a horizontally-stacked fraction.  Without font override, the content entry looks like this:

(1 . "\\A1;{\\H0.7x;\\S3/4;}\" conduit")

With the font override of all content, it looks like this:

(1 . "\\A1;{\\fSwis721 BT|b0|i0|c0|p34;\\H0.7x;\\S3/4;\\H1.429x;\" conduit}")

Note that the \\A1 thing [which is not preceded by a left brace as other internal-formatting codes are], which indicates that there's at least one stacked fraction somewhere in the content [the 1 is for vertically-centered stacking], comes before the {\\f part about the font override.  And note that one opening left brace and one closing right brace encompass both the Font override and stacked-fraction codes -- the left brace immediately before \\H is gone.  And that the height assignment for the stacked-fraction numerator and denominator needs to be reversed internally with another \\H entry, since the braces-surrounded content now extends beyond the part with the fraction's Height override, to include everything within the Font override.

Or say one starts with part of its content given an override Color.  Without the font override, "This is a test." with the first word in red [color 1] looks like this:

(1 . "{\\C1;This} is a test.")

With the font override, it looks like this:

(1 . "{\\fSwis721 BT|b0|i0|c0|p34;\\C1;This\\C256; is a test.}")

That has the same kinds of conflated-internal-coding issues between Font and Color overrides as the previous example does with the stacked-fraction and Font override.  So adding the green gobbledegook prefix and right-brace suffix first mentioned above, which should work for Mtext with no other internal formatting, would not work right on these other possibilities.  Combine a Color override with Underlining, and/or Boldface, and/or another partial Font override, and/or .... you see where this is going.

It just seems overwhelmingly complicated to have a routine account for all possible combinations of internal formatting that might need to be combined with an all-encompassing Font override, in order to get the text-content adjustment right.  Doing it manually in every Mtext object after the fact also seems ridiculous.

EDIT: And get this -- if, in Mtext with no other internal overrides, you select it all manually and assign the same font that's in the Style's definition [which is presumably what you would do, to retain the font you're used to but as an internal Font override], it has no effect on the textual content!  The font override does not appear in the code-1 entity data entry, but is ignored, since it's not different from the font the Style is already using.  So when you then assign the other company's Style as an "outer" Style assignment to the Mtext, it will change the look of the content, to something different from what you're used to.  And that, of course, will also change the size of the Mtext, potentially the number of lines where word wrapping is involved, etc., etc.

Not to mention that changing Text to Mtext sometimes alters its position a little, and can even result in its breaking to two lines....

I suggest you have your drafters just buckle down and get used to using a different font in work for any company that wants such a thing in the product you turn over to them.