Here's A Good One

When you receive a drawing from a consultant and they are so wise as to send
along their .ctb or .stb, it would be nice to have automation to ask for the
plot style table YOU want to use and then read the consultant's plot style
table and map (as close as possible) to your desired plot style table.

With this capability, you would eliminate the need to permanently store the
outside plot style table and could work with yours with which you are most
familiar.

 

Better yet, the ability to be able to attach the stb/ctb configurations
within the DWT template file. This way the drawing file has everything you
need. The ctb file is usually less than 6 kb ...what's the big deal in
adding it as part of the drawing. Should be allowed to include a few ctb
files within the template file (11x17, full, etc.).

 

they are so wise as to send along their .ctb or .stb

I never give anyone our CTB, because it is hardware dependent and will only
cause them grief. CTB's don't have to be this way, but they very easily can
be, therefore it's a mistake to assume that they are universally useable.

Having the OPTION to bind CTB's into the drawing would be alright, for those
who are willing to make the giant leap of faith required, but doing this
unconditionally would be a nightmare for us.

 

Can't say I have ever heard that one before.
I get tons of .ctb files from our clients and
have never gotten any "grief" from it. Really
just the opposite, I have more problems if they
don't send them. Perhaps I/we are lucky?

 

Hi Tom,
I'd have to disagree with CTB's being hardware dependent. Like Jason,
I receive and send them all the time. It's the pagesetups that are hardware
dependent and also the PC3 files.

Regards,
Doug

 

I suppose you could view the .ctb as partially hardware
dependent, endstyles and screened percentages, etc...
could vary slightly depending on the device but I can't
say that creates any grief from my point of view. I'd
rather have somethin' than nuthin'.

 

Hi Jason,

That's true. Optimum plotting will vary by device. A 50% screen on
one plotter will appear darker on one plotter than another. I too like
to have a starting point. I hate the missing CTB messages during plotting
and those using CTB's with lineweights generally follow office standards
for lineweight to color settings vs some national standard. It takes a lot
more effort to adjust plots without the CTB's.

Regards,
Doug

 

Wow, it seems more people are still using Color Dependent plot styles than I
thought.

Named styles haven't really caught on, I guess, even though I couldn't live
without them.

Is it an ADT issue?

Don

 

I have barley even looked at .stb but, the color does
not equal lineweight concept is foreign to me and
would be tough to switch over.

 

I just think it's so cool to identify a layer's plot style as SHADE, HEAVY,
MEDIUM or LIGHT, etc...

It really helps me when I receive Architectural backgrounds with many
colors.

I usually want the backgrounds to plot shaded to highlight my piping
systems.

Don

 

I fail to see how this sample is even remotely relevant
to the argument that .ctb files cause grief. That file
prints just like the .ctb file tells it to.

If the .ctb file actually had the weights/screening defined
(like most .ctb files do) how could there be a problem
with printing this file?

'fraid I just don't see your point, please explain.

 

Tom,
I'd agree with Jason again.
a)1.The ctb says to use object lineweights.
2.The object lineweights are bylayer.
3.The layer has a default lineweight assigned.
4.All colors in CTB plot black and 100% screened.
5.The only difference in CTB is virtual pens (which I never use).
b) Irrelevant since the textual information beside each line has nothing
to do with the CTB settings.

Is it possible to send a poor CTB? Yes.
Is it possible to customize the OOTB CTB's so that those plotting
in another office will be deceived? Yes. That is why if I customize CTB's
I use
a unique name.

CTB's will be needed as long as archival drawings need to be plotted and
until
automation routines that rely on color=lineweight are updated.

Regards,
Doug.

 

I fail to see how this sample is even remotely relevant

Jason, my argument was that MY ctb files are hardware-dependent and
therefore of no use to anyone else in achieving the intended
color-to-lineweight correspondence. Fortunately, we practically never share
files with anyone else, so it's not normally a problem. But in the rare
cases where someone else needs to plot one of our files, our ctb won't help
them. Obviously ctb's aren't necessarily a source of grief, but they can be,
if they cause confusion and/or false expectations of trouble-free plotting.

That's my point: our ctb files don't contain this information, and since
they don't, you aren't going to get the intended lineweights and screenings
by plotting from our ctb's. Granted, we do things in an odd way, but since
it doesn't cause us a problem, so far, there hasn't been sufficient reason
to fix it.

In the wacky system that I inherited, our plotters are configured to act
like old fashioned pen plotters. The ctb, and therefore the plot files,
contain only "virtual" pen numbers, not lineweights, and therefore the
plotted appearance depends on how those "pens" are programmed on the
plotters. On our plotters, the sample drawing plots each line just as it's
labeled. But since there are no other plotters on earth programmed in the
same way, nobody else can get a correct plot from those ctb's. By the same
token, we can't plot from anyone else's ctb's either, because regardless of
the lineweights given in the ctb, our plotters will override them according
to the hard-wired pen settings.

Maybe it's a very unusual and slightly outlandish situation, but my argument
was that ctb's CAN be implicitly hardware-dependent, though clearly they
shouldn't be. For most people, it's probably pretty reasonable to assume
that both the producer of the ctb and the recipient have a relatively
up-to-date plotter, and that they've chosen (by design or accident) to set
up their plotter in a way that reflects smart practice. But I'm playing
devil's advocate by pointing out that those are only fairly safe
assumptions, not known facts. (Looking back at all the various discussions
here, in how many instances would it be valid to assume that everybody
always does things in the smartest way in Acad?) It's within the realm of
possibility to create a valid ctb that's useless to anyone else.

But you raise a good point -- I think our ctb's could be made to "play nice"
by adding weight/screening information, even though that info would be
superfluous and ignored by our plotters, but AFAIK it wouldn't hurt to have
it in there anyway. I'll need to look into that.

 

I see, thanks for the clarification.

I gave up on hardware pen settings long time ago

 

Thanks for the clarification. If that was your CTB, I can see
how it wouldn't be much help to consultants.

Regards,
Doug

 

Doug, see my reply to Jason. Our ctb's rely on the virtual pens, which
reflect hardware pen settings on our plotters. I certainly won't argue if
you consider that a "poor" way to plot! But for legacy reasons, we're stuck
with it, at least until there's a really powerful reason to change.

As I expected, the example ctb apparently resulted in a plot which is
legible but incorrect, having none of the intended lineweights or
screenings. On a real drawing, this would be a problem, since both are used
to convey meaning. And as your comments show, the ctb is deceptive, since it
conveys none of this information. The lineweights aren't controlled as the
ctb seems to imply they are.

Your comments on archives touch on the dilemma we face. Our business is
unusual in that we sell prints of plans. We very rarely exchange electronic
files with anyone. We have many thousands of archived plot files, which are
sent to the big plotter to fulfil orders. Therefore, we can't change the
crazy hardware setup without replotting every existing file and
reconfiguring the plotter. As long as the system works for us, internally,
we don't have any incentive to do this.

Clearly this is sort of an extreme case, but I think it's worth noting that
ctb files are not necesssarily universally compatible, as people tend to
believe who haven't grappled with a scenario like this.

 

Tom,
Thanks for the clarification. I can understand the need for continuity
of archived and current drawings. No need to worry about efile
compatibility
if you don't exchange drawing files either.

Might be a good time to add a new CTB file that reflects the settings of
your
existing one, but which relies on device independent settings (if your
current
plotter supports it). Then you could use the new CTB file settings for your
new work and it could still remain compatible with the your old files.

<aside>
So many recent changes have occured in CAD and Building Information
Modelling
that it is becoming difficult to predict what CAD system most offices will
be
using in 5 years. [Revit, ADT, ArchiCAD, AutoCAD....]
</aside>

Regards,
Doug

 

Might be a good time to add a new CTB file

That's certainly worth studying, though for us it's a back-burner issue.

The old HP's we use for in-house progress prints wouldn't cooperate, because they must be set for either hardware or software pen control. But the transition there wouldn't be too painful.

On the big Oce, with the server full of old plot files, it's possible to have multiple pen mapping files (sorta like ctb's but on the plotting side) and I think it might be feasible to change methods while still maitaining backward compatibility. My to-do list keeps growing!

 

I have barley even looked at .stb but, the color does

Jason, I'm with you. The named styles sound appealing from a drawing
management point of view, but I'm strongly conditioned to having a visual
cue to lineweight on screen. If the colors don't correspond to pen weight,
then I'd want to see the object lineweights displayed. So far, I haven't
seen a strong reason to make the change.

 

Lineweights being displayed would help but not
sure how accurate they are since they seem to
change in appearance depending on your current
zoom factor.