Surfaces in blocks print differently than on their own?

I dug this out:

(New Feature: Rich Text)

Is that no longer the case for R6?

Brian, The point is its a step file. It opens in 5 and it should just open in 6. Recent bug submission or not. Some basic things that should have just work right out to the box didn’t and it seems there is now a reluctance to fix.

What I am seeing in these posts is that for users (including me) Rhino is a tool that we use to make our living. We just want it to work so we can do our jobs and go home at night. And if we go home and take Rhino with us its to develop something cool and useful for us (like a working B.O.M that works in Rhino for me, or if one of my guys its building a deer stand or a pinewood derby car) and not work on work arounds for something that should just work

Everyone here loves Rhino otherwise we wouldn’t be wasting our weekends and time during or work day posting to this.

Great. I’ve moved RH-52277 to V6 as a regression.

Mia culpa. I’m sorry to lay false blame.

No, there’s not a way to tell Rhino at all that the leader text should align automatically to the tail. The fix @lowell recently put into V6 is to be able to read V7 files with this new dimension style setting, but basically ignore it and make it be one of the other values (perhaps left justified, I don’t really know the details).

Nope, it’s no longer the case.

If we get this pdf printing issue and keyboard shortcut resolved, I’ll forgive your little transgressions and we can move onto conquering the world with R7. :wink:

I solved the leader justification with this (since we’re using script to plop them):

Ldr = rs.coercerhinoobject(Ldr_GUID, True, True)
Ldr.LeaderGeometry.LeaderTextHorizontalAlignment = Rhino.DocObjects.TextHorizontalAlignment.Right

You’re off the hook with this one. :wink:

That’s great to hear - @lowell it looks like the test command we talked about earlier isn’t necessary for V6.

1 Like

Still not fixed in image


This is not fixed either.

1 Like

RH-52539 is fixed in the latest Service Release Candidate

RH-52539 is fixed in the latest Service Release Candidate

1 Like

Not fixed.


Updated version installed this morning (6/12/19).

@Mason it’s hard to tell from your screen shots what you are showing. Can you please describe the process you used to generate each screen shot? We may be testing different things here and getting different results.

We have a set of drawings for our detail connections that we have drawn in plan/2D.
We have had these created in R5 with lines, surfaces, and a hatch and then grouped together and when printed through a layout detail (viewport) in Ghosted mode, the surfaces print as displayed on the right hand side of the screenshot.

In R6, we decided to contain these groups within a block for better rendering performance since rhino only has to render the blocks once for each drawing. But when contained within a block, the print properties of the contained geometry changes to something else entirely,(the left and center images) and does not print the same as if not contained by the block.

Seems to be fixed here.

I believe I was using a sample from @Asterisk to repeat and fix the bug which is probably why his bug appears fixed. @Mason there must be something slightly different about your case. If you have a simple sample that I can use to repeat what you are seeing, I sure would appreciate it.

The issue is back in 6.17 :frowning:

1 Like

It looks like this is still an issue and I just wanted to make sure it’s still being looked into. Also, some additional info that might help identify the problem, when blocks are selected they print highlighted just as they appear on the screen. The same is not true for surfaces/ exploded blocks, even if selected they will print as the display color.
RH 52539

hihglighted block.pdf (816.6 KB)

Could it be that when this bug is present, regardless of the print colour set in a layout’s detail view, surfaces in blocks print by the global print colour.

I think this is the case in the Rhino version I am using.

I’m using Rhino 6 sr11 18348.17061,12/14/2018 because since that version, dimensions less than 6’ don’t have dimension lines (at least not if the units are set to feet and inches.) A bug not to be corrected until Release 7 I am told. I would like to add this to the list of shortcomings which really should not remain until version 7.

Hi Djhg,
I wanted to review how we are expecting Rhino to behave in this area.
Annotation Objects: Curves, Hatch, Dimensions, Text

  • Display Color: Yes
  • Print Color: Yes
  • Black & White (monochrome): Yes


I was able to repeat the following issues and logged it as RH-54873.
When the surfaces area part of a block instance, and the Print Color is set to Black & White or Print Color and the Detail display mode is set to Ghosted, the surfaces are not previewing or printing with the correct color.

Here the surfaces are set to display color of cyan. But when they are group into a block, they are in error using the print color, not the display color like they should be:

Print Color previews on the display like this:

But Print Color prints and preview like this:

But Black and White Color prints and preview like this. Not in the same grayscale as the individual geometry.

Let me know if that captures the issue correctly. I can add any additional details to RH-54873.
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA

You’re 100% correct.
This already has been fixed in 6.16, but it seems like it wasn’t adopted in all the consecutive releases.

Hi Asterisk,
Thanks for letting us know that the issue has returned.
It appears that his issue was fixed by RH-52539 in Rhino 6 sr15 for all Display modes, except Ghosted.

We have logged as RH-54873 Surface in Blocks Not Printing Correctly in Ghosted Details.
We will let you know then RH-54873 is fixed ready for testing.

Thank you.
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA

1 Like