Before, our leaders were generating so that the leader was by layer and the text was yellow. The layer that they come in on is set to green, so we had a green arrow, yellow text.
How the whole thing is set to color by layer. I'm not sure how this changed, but most importantly, how do I put it back to how it was? I don't see this as a setting in my preferences, but I'm sure it's somewhere.
How the whole thing is set to color by layer. I'm not sure how this changed, but most importantly, how do I put it back to how it was? I don't see this as a setting in my preferences, but I'm sure it's somewhere.
Hi Katherine,
The leader with text tool was updated so that the leader and text use the same line color. This was done because it caused issues with the text having to be set to a specific colour in the mleader properties, and then that colour not being colour by layer. The same was done for our default dimension styles.
It's not possible to save in any alternative defaults to have the text appear as a different colour in the leader styles.
However, on the plus side, the reason we ended up doing this is because the colour assigned to text does not actually affect the boldness at which it plots. Text is not affected by ctb files. You can try this out by doing a plot preview with the LFX.ctb plot style with some red text and blue text. They plot exactly the same thickness, while lines set to red and blue plot different thicknesses.
So this all means that having the text at a different colour than the leader does not actually affect the plot thickness of the text. To get bolder text, use a bold style font. We've introduced new ideal font standards to deal with how AutoCAD plots fonts. We're starting to recommend the Swiss 721 family of fonts since they have thin, regular, bold and black versions.
-Amanda
The leader with text tool was updated so that the leader and text use the same line color. This was done because it caused issues with the text having to be set to a specific colour in the mleader properties, and then that colour not being colour by layer. The same was done for our default dimension styles.
It's not possible to save in any alternative defaults to have the text appear as a different colour in the leader styles.
However, on the plus side, the reason we ended up doing this is because the colour assigned to text does not actually affect the boldness at which it plots. Text is not affected by ctb files. You can try this out by doing a plot preview with the LFX.ctb plot style with some red text and blue text. They plot exactly the same thickness, while lines set to red and blue plot different thicknesses.
So this all means that having the text at a different colour than the leader does not actually affect the plot thickness of the text. To get bolder text, use a bold style font. We've introduced new ideal font standards to deal with how AutoCAD plots fonts. We're starting to recommend the Swiss 721 family of fonts since they have thin, regular, bold and black versions.
-Amanda
I was afraid you'd say that.
What you say about color not affecting plotted weight is true if you don't use SHX fonts (see attached). Alas, we do. Are we truly the only customer you have that uses SHX fonts? Le sigh.
What you say about color not affecting plotted weight is true if you don't use SHX fonts (see attached). Alas, we do. Are we truly the only customer you have that uses SHX fonts? Le sigh.
Katherine,
Having the text color be ByLayer is a must-have, so that's not going to change. So it's a matter of working around that.
You can set the Leader line color to be the desired text color, or you could go with a TrueType font (such as this one: http://ttfonts.net/font/35864_Simplex.htm).
--J
Having the text color be ByLayer is a must-have, so that's not going to change. So it's a matter of working around that.
You can set the Leader line color to be the desired text color, or you could go with a TrueType font (such as this one: http://ttfonts.net/font/35864_Simplex.htm).
--J
That's fine, I'll figure something out. It's just going to take a non-zero amount of work. If it were a matter of changing one leader it would be no big deal, but it's a matter of making all future details match the details already in our library.
Changing our firm's standard font would be a very non-zero amount of work-- not a fight I am ready to take on. I am really curious about whether we are the only firm on the planet still using SHX fonts.
Changing our firm's standard font would be a very non-zero amount of work-- not a fight I am ready to take on. I am really curious about whether we are the only firm on the planet still using SHX fonts.
There are plenty of firms using SHX fonts, although the correct phrasing would "still stubbornly using SHX fonts."
It's really been a decade since there was a viable argument to using SHX fonts.
With mounting needs of PDF generation, and collaborating with other design platforms, at best you are just postponing the inevitable by sticking with SHX.
--J
It's really been a decade since there was a viable argument to using SHX fonts.
With mounting needs of PDF generation, and collaborating with other design platforms, at best you are just postponing the inevitable by sticking with SHX.
--J
Katherine,
We "still stubbornly use SHX fonts". I'm sure that this is no surprise to Jeremiah. The reason that we do it t is two fold:
1. We can use the same font on different colored layers to print differently. This is importation to all of use whom share files with different disciplines. For instance, the Civil can place some text in the drawing that he/she feels is important to their story. They may use a heavy pen to get the story across. As the LA, we also need the text, but it's not as important so we can use a thin pen, or even screen it back. That's why it's still important to use SHX fonts. Of course if a font style was used, we could modify that, but we can't depend on everyone having a different font style for every element. That's just too complicated in a large firm.
2. SHX fonts print in a fraction of the time. To test this, create a 24"x36" sheet filled with notes (or specs.). Have the style defined with an Aerial font. Send the sheet to the printer. Time it (though it will be obviously slower), then change the style to a romans.shx font. Now print it again. It should take less than half the time.
So yes. We still use SHX's. Further, While our CALLOUT TITLE style points to Arial .TTF), our DETAIL TEXT style points to Romans.shx. So like you, changing to a different font would not be a non-0 amount of work.
Good luck with your efforts.
Seaweed.
We "still stubbornly use SHX fonts". I'm sure that this is no surprise to Jeremiah. The reason that we do it t is two fold:
1. We can use the same font on different colored layers to print differently. This is importation to all of use whom share files with different disciplines. For instance, the Civil can place some text in the drawing that he/she feels is important to their story. They may use a heavy pen to get the story across. As the LA, we also need the text, but it's not as important so we can use a thin pen, or even screen it back. That's why it's still important to use SHX fonts. Of course if a font style was used, we could modify that, but we can't depend on everyone having a different font style for every element. That's just too complicated in a large firm.
2. SHX fonts print in a fraction of the time. To test this, create a 24"x36" sheet filled with notes (or specs.). Have the style defined with an Aerial font. Send the sheet to the printer. Time it (though it will be obviously slower), then change the style to a romans.shx font. Now print it again. It should take less than half the time.
So yes. We still use SHX's. Further, While our CALLOUT TITLE style points to Arial .TTF), our DETAIL TEXT style points to Romans.shx. So like you, changing to a different font would not be a non-0 amount of work.
Good luck with your efforts.
Seaweed.
Cycling back to the original issue: the text being a different colour than the leader in a multileader text callout.
If you look at mleader styles, while you can set the text on a different colour, you can't set it on a different layer. We had a different method when we first implemented mleader text that allowed the two-colour system.
The way the system achieved a different colour before was to take the old text layer colour from the preference sets and set the text colour to that instead of BYLAYER, and then the leader would by bylayer and take on the ANNO layer colour.
This came up from several user requests as an issue because that text could not then be simply changed in a viewport or xref to be thinner or grey, since it was embedded into the multileader properties. It would take a lot more non-zero work to fix the embedded leader properties to be BYLAYER.
We find setting everything to BYLAYER as a critical benefit for universal standards, and using multileaders as a much better system than the old separate leader and text. Since it's not possible for the text in an mleader to be on a different layer, it's now the same colour as the leader to allow BYLAYER benefits.
I'll look into tagging it into the wishlist to have a more robust mleader style preferences, but it would be a very complex fix to implement.
-Amanda
If you look at mleader styles, while you can set the text on a different colour, you can't set it on a different layer. We had a different method when we first implemented mleader text that allowed the two-colour system.
The way the system achieved a different colour before was to take the old text layer colour from the preference sets and set the text colour to that instead of BYLAYER, and then the leader would by bylayer and take on the ANNO layer colour.
This came up from several user requests as an issue because that text could not then be simply changed in a viewport or xref to be thinner or grey, since it was embedded into the multileader properties. It would take a lot more non-zero work to fix the embedded leader properties to be BYLAYER.
We find setting everything to BYLAYER as a critical benefit for universal standards, and using multileaders as a much better system than the old separate leader and text. Since it's not possible for the text in an mleader to be on a different layer, it's now the same colour as the leader to allow BYLAYER benefits.
I'll look into tagging it into the wishlist to have a more robust mleader style preferences, but it would be a very complex fix to implement.
-Amanda
Amanda,
I couldn't agree with you more. I love that part of NUKE too. As part of a multidisciplinary team we must allow other disciplines to have control over how our information prints, and visa versa. And the newer leaders are far better than the old ones. Thanks again wizards at LandFX!
Seaweed
I couldn't agree with you more. I love that part of NUKE too. As part of a multidisciplinary team we must allow other disciplines to have control over how our information prints, and visa versa. And the newer leaders are far better than the old ones. Thanks again wizards at LandFX!
Seaweed
Amanda, I agree 100% that having everything set to BYLAYER is a better strategy overall. I'm just trying to figure out the most efficient way to negotiate the change so that our existing detail library will appear consistent with new details. Opening each detail file, selecting the text in each individual leader, and changing it to BYCOLOR sounds like a lot of tedious and unbillable hours.
Does anyone have any ideas about how to automate that? Would a LISP routine be able to do something like that? I have not yet ventured into LISP territory, but this might be the time...
Does anyone have any ideas about how to automate that? Would a LISP routine be able to do something like that? I have not yet ventured into LISP territory, but this might be the time...
To clarify, your existing standard is for leader text to be Yellow and the leader to be Green? And the new standard is for both to be Yellow, correct? Why does that require updating all details to match? Are you saying you have gone through all details to update all leaders to be MLeaders with attached text?
Our BatchMan tool is key in updating details to bring them up to current standards. But it can't convert separate text and leaders to a single MLeader, it can't recombine exploded or I associated dimensions, and other such tasks. It does, however have a Color ByLayer capability, which should be able to take care of this task -- and if it is not able to set the embedded text within an MLeader to ByLayer, that would be an easy fix.
--J
Our BatchMan tool is key in updating details to bring them up to current standards. But it can't convert separate text and leaders to a single MLeader, it can't recombine exploded or I associated dimensions, and other such tasks. It does, however have a Color ByLayer capability, which should be able to take care of this task -- and if it is not able to set the embedded text within an MLeader to ByLayer, that would be an easy fix.
--J
Amanda,
I'm wondering if Batchman could help her change their old details to match the new style?
Seaweed
I'm wondering if Batchman could help her change their old details to match the new style?
Seaweed
- Page :
- 1
There are no replies made for this post yet.
Contact
- Land F/X
Our software tailors AutoCAD® to the needs of landscape architects, irrigation designers, and other professionals. We automate your most tedious tasks and ensure accuracy, giving you more time to design.