Jump to content
jkoll66

Backgound mask showing in some viewports on plot

Recommended Posts

jkoll66

Hi, I have a drawing that incorporates a number of Multileaders that consist of a rectangle with some text inside and a background mask. This drawing is then Xref'd into another drawing.The issue I'm having is that in the main drawing I have frozen some of these. However, the background mask is still showing on the plotted drawings. I've tried to "Select All" to see if something shows up in the drawing, but to no avail. Any ideas? Thanks.

Edited by jkoll66
Changed Dynamic blocks to multileaders

Share this post


Link to post
Share on other sites
Dana W
Hi, I have a drawing that incorporates a number of Multileaders that consist of a rectangle with some text inside and a background mask. This drawing is then Xref'd into another drawing.The issue I'm having is that in the main drawing I have frozen some of these. However, the background mask is still showing on the plotted drawings. I've tried to "Select All" to see if something shows up in the drawing, but to no avail. Any ideas? Thanks.
These ideas may not help but here they are anyway...

 

In the xref'ed drawing, these leaders may be using something other than the drawing background color for a mask. If the leaders have a block with a text attribute attached to them, perhaps the block was saved in the block editor, on a layer other than the one the leader is inserted on, and that block's layer is not frozen in your viewport. Note that a block can be a text attribute with nothing else, so a mutileader with that 'user block' attached will look like a normal multileader with text only when it is in fact a custom multileader.

 

EDIT: See the bold text above. I think that may be the answer. I missed the part about the rectangle on first read. You do have a multilieader with an attributed block attached. Any of the individual parts of the block may have their own object properties, or as I stated above, the block or any of its parts may have been created on any layer inside the block editor, and that layer is not frozen in your viewport. Just being a simple attributed rectangle, it may or may not be one that comes canned with AutoCad. If it came with AutoCad it is almost certainly created on layer 0. If it is custom, it could have been created and saved on any layer. If the block is one of AutoCad's, and created on layer 0, then it should have taken on all of the properties of the layer the leader is inserted on, including being frozen in a viewport.

Edited by Dana W

Share this post


Link to post
Share on other sites
jkoll66

Thanks for the reply. The multi-leaders are not blocks. I went into properties and what I described incorrectly as a rectangle was instead a "Text Frame". These leaders had a number of annotation scales associated with them, I had deleted all of them with the exception of the one I actually needed. Could that have thrown things out of whack somehow?

Share this post


Link to post
Share on other sites
RobDraw

Probably not anything to do with annotation scales.

 

Your terminology is off, so post a portion of the file exhibiting the behavior to make sure we are on the same page.

Share this post


Link to post
Share on other sites
jkoll66

I've attached the multileader in question. If you need more of the drawing I'll have to get permission to upload it from the "Superiors". Thanks.

Multileader.dwg

Share this post


Link to post
Share on other sites
RobDraw

I'll look at it early tomorrow AM, if no one has a chance before then.

Share this post


Link to post
Share on other sites
Dana W

Well, I don't know where to go with it, now. When I freeze the layer through the active viewport, it goes away.

 

You are clicking the VP Freeze icon, and not the New VP Freeze one, right? You are doing that while in the active (in model through the) viewport, right?

 

Wait. I forgot about the "plotting" part. Hold on the above.

 

EDIT: Ok, no background plots either.

Share this post


Link to post
Share on other sites
Dana W
Could that have thrown things out of whack somehow?
Nope. (argh message too short.)

Share this post


Link to post
Share on other sites
Dana W

OK, I have verified that the text does have a background mask, and it is the drawing background color by default set in object properties by selecting a simple Yes or No.

 

Are you by any chance using a crazy whacky personal custom ;)background color in modelspace that the plotstyle simply cannot handle, like a color not included in the index colors?

 

For instance, your custom plotstyle is of course, missing on my computer so I substituted monochrome.ctb. Because the red 266,0,25 in your company logo is not an index (1 to 255) color, monochrome.ctb skips over processing it, and it plots as red instead of black.

Share this post


Link to post
Share on other sites
RobDraw

It won't plot for me. Can you post a portion of the file that you are XREFing it into?

Share this post


Link to post
Share on other sites
jkoll66

Sorry for the late response. I was able to get it to print properly by going into the plotter properties dialog and changing a setting in "Merge Control" to lines overwrite. A colleague of mine says changing this could cause issues with transparencies, but so far I haven't seen anything. Apparently this is a known issue dating back to 2011. Thanks for taking the time to try and figure this out for me.

Properties.jpg

Edited by jkoll66
grammar

Share this post


Link to post
Share on other sites
RobDraw

I'm pretty sure it goes back even farther than that.

 

The Lines Overwrite option can be an issue if you have shaded (screened) objects over ones that plot solid. The shaded one can take precedence creating a break in the solid one.

Share this post


Link to post
Share on other sites
jkoll66

Thanks for the info. We do have some blocks that are shaded. I'll keep an eye out for issues. You would think Autodesk would have fixed this by now...ha ha ha.

Share this post


Link to post
Share on other sites
Dana W

Draw order takes charge in the "Lines Overwrite" thing. The line in front plots, no matter if it is light over dark, the front shows while nothing is plotted behind it. It's not an issue. It is an option.

Share this post


Link to post
Share on other sites
RobDraw
Draw order takes charge in the "Lines Overwrite" thing. The line in front plots, no matter if it is light over dark, the front shows while nothing is plotted behind it. It's not an issue. It is an option.

 

IME, draworder is not 100% reliable. It also puts too much onus on our inputters.

Share this post


Link to post
Share on other sites
Dana W
IME, draworder is not 100% reliable. It also puts too much onus on our inputters.
Show me 100% reliability anywhere. And don't look for it in our inputers.:lol:

Share this post


Link to post
Share on other sites
RobDraw

I could have dropped the 100% from that statement and it would have more accurate. Plus, for printing, aren't we actually talking about display order? I believe they are different.

Share this post


Link to post
Share on other sites
Dana W
I could have dropped the 100% from that statement and it would have more accurate. Plus, for printing, aren't we actually talking about display order? I believe they are different.
I'm not familiar with Display order. Could it be "Plot Paperspace Objects Last"?

 

EDIT: I looked it up. Display order IS draw order. (at least as much as I get from the severely and purposely obfuscating language in AutoCad Help).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×