Backgound mask showing in some viewports on plot

[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 August 10, 2016 by jkoll66
Changed Dynamic blocks to multileaders

[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 August 11, 2016 by Dana W

[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?

[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.

[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

[RobDraw]

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

[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.

[Dana W]

Could that have thrown things out of whack somehow?

Nope. (argh message too short.)

[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.

[RobDraw]

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

[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.

Edited August 30, 2016 by jkoll66
grammar

[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.

[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.

[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.

[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.

[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.

[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.

[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).

[Andy1024]

Checking the "Plot Transparency" box in the plot settings fixed this issue for me.

[CadLover]

I had the same exact problem and found that the xrefoverride system variable should set to 0. This solved the problem.