In Living Style Deux?

Thanks for all of the comments on Named Plot Styles. 

In switching a few years ago, from color to named styles, we had the impetuous to switch.  We added enough staff that we really needed to re-document things to bring the new staff up to speed.  After 12 years arguing about if color Red was thick or thin, or Color 8 was supposed to plot with virtual pen 3 or 6, the confusion really got to me.  There has to be a better way – something a little more WYSIWYG and a little more understandable. 

What is the difference between the two methods?  In my opinion, not much.  It simply is a matter of a look-up table from Layer or Object to either the CTB or STB plot style table.  We all “plot” in one way or the other.  😉  [I still have an old pen plotter in my basement]


The image above is the Plot Style Table from acad.ctb.  Pretty familiar.  There are a lot of settings available.  255 different colors,  2 dithers, 255 pens, 255 Virtual Pens, 100 different Screenings, lots of linetypes, lightweights, end styles, join styles, fill styles, etc.   More possible different plot styles and configurations than I want to think about! 

Our CTB really only has settings for colors 1-16, 41, and 250-255, 8 different lightweights, and 8 different “virtual pens”.  It’s still available for legacy printing. [Don’t ask about #41 – I don’t know]

Our first iteration of STB went over like a lead balloon.  We mapped a named plot style to something like BLACK-0.07, and BLACK-.014 etc.  There were 32 different options – too many than what Color offered.


This is what we settled upon:  Black, 5 different possible screenings of Black, Color and screened Color.  Most of the Black shades don’t get used in our template.  I like it for its simplicity.  Our template has Black, 50%, and one 15% layer.

Object lightweights are now in play on a bylayer setting.

So, how does this sound so far? 

Civil 3d does pose some challenges to using Named Plot Styles.  I wish that the settings were available everywhere in a Civil3d Object styles, but they are not everywhere.  The biggest problem is labels.  It works well in some cases, not well in others as some of you noted in my earlier post.


  1. Dustin Manning says:

    So, I see that I am STB ignorant. What colors are displayed on-screen? It seems like everything would be black and you would have lineweights displayed also? I’m missing something that I’m sure is obvious.

  2. Any color you like! The Layers have colors – which obviously helps us visually see what object is what layer. Paperspace does have the “WYSIWYG” setting of “Display Plot Styles” that works with both CTB and STB.

    Lineweight can be toggled off and on.

  3. Back when release 2000i came out I decided to re-standardize taking advantage of lineweights by object. It provides an infinite amount of flexibility to the users while removing the color dependency issue you mentioned. My user’s have had similar challenges where they are used to identifying a color on the screen with a certain printed lineweight. So, we try to match certain colors to certain lineweights but do it through the layer properties instead of the CTB. It’s been very successful for the past eight years or so. This system allows for data to be transfered from another competitors product an retain their lineweights as well. It’s great to have options!

  4. Neil Wilson says:

    One of the headaches I’ve had with STB’s is how to establish style naming conventions. When naming the styles we want them to be intuitive such as in your example above (i.e. Black 0.07, etc). Once your drawing is mapped to the style table then all style tables must have identical style names or there will be a mismatch. In the example above, if you now want to set up a color style table for color plotting you will need to create the same style names (Black 0.07) etc. in your color table yet those styles are not going to be printing in Black now. What started out to be an intuitive naming convention now is the opposite. Your options are to get everyone used to the reverse intuition or to remap your layers to a table with diffrent names. If over timne you decide that your naming convention needs an overhaul then all the tables will need to be re-synchronized to the new naming convention which can be a lot of work. With CTB’s there are no style names and no mismatches to worry about. While I like the concept of STB’s I have run into enough headaches to stay away from them…for now.

  5. Color in a STB is as simple style called “COLOR” with a setting “Use Object Color”.

    If you take lineweight out of both STB and CTB – life can be simpler. Now we can use all 255 colors!

  6. Neil Wilson says:

    If I understand your reply Matt, you can set up a style called COLOR in your STB and thus you can plot in both color and B&W in one STB which comes in handy. However many companies set up seperate plot style tables for plotting in black and white or color or grayscale or for different plot devices, etc. By setting up multiple style tables it is simply a matter of applying a different style table to a page setup verses going through the layers and remapping them to a color style vs. B&W style. It was in that context that I made my comments. Thus if you set a style called COLOR in your B&W table you would also need to include it in color.stb and grayscale.stb in order to prevent a mismatch. Now as an example, if a user is working with Color.stb and sees the Black 0.07 and COLOR in the style list, what would he expect those styles to mean? He would expect that if he uses Black 0.07 he will get black outut so he would avoid using it and opt for the Color style. The reality is that Black 0.07 was defined in B&W.stb and has been included in color.stb to avoid a mismatch. In color.stb, Black 0.07 is configured for color output so that drawings set up with B&W.stb can be printed in color using color.stb. Which style should the user apply? I have gone around and around on how to work with the multiple style tables and naming conventions. More than once I thought I had something figured out only to get spun around when a scenario arose that I hadn’t anticipated which threw a wrench into the whole naming strategy and then I had a huge mess to try to reconfigure everything.

  7. Neil –
    We use one file: JAS-Standard.stb for ALL cases – color, black, and grey. There is no guessing which STB file this layout is using. Lineweight was taken out of the STB. See the second image for how simplistic it is.
    What you described was how we did it with CTB – a “color-weighted” CTB, and “Black&White weighted CTB, a scaled B&W CTB. It is confusing. Is my cyan property line going to plot in color, black-.021, or black-.01 or is it screened? I don’t know until I visit the plot dialog box. I think the biggest benefit of STB is removing that questions from the plot dialog box to the layer dialog box – how is this layer going to plot? Moving lineweight to the layer dialog box also helps.
    Named Page Setup provides a mechanism to “Scale” lineweights for reduced sets of plans.

  8. Neil Wilson says:

    I’ll present a case where it was necessary to use more than one plot style table. I was creating maps of an As-built water network for a client. They want 2 versions of the maps, one as Black and white line drawings and one with the network overlaid onto color photos. Both sets of maps had the same annotation and line work but the maps with photos needed to have the linework and annotation in color to get sufficient contrast to be readable. The practical solution here was to create both sets of maps in the same file and vary the output using plot style tables. If we were standardized on a single table we would have to create 2 drawings and keep them sychronized, something we want to avoid whenever possible, or we would have to create a custom table for this particular drawing or project and every other case when this scenario arises again creating more management overhead.

  9. One drawing – two tabs – Viewport overrides or Xref and override in “Second” Drawing.

  10. Neil Wilson says:

    You make a good point. With ACAD2008 we have the ability to apply viewport overrides which in this case would work well. However we (and many other firms) have not upgraded to 2008 (us for reasons I’ll not mention here). Viewport overrides take away most if not all the issues that STB’s presented in the past. I tend to forget that when I bring up these arguments, but for the sake of those who might not have override capabilities I hope it helps to anticipate these issues before embarking on path to STB’s.