Surfaces in blocks print differently than on their own?

[RBL]

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.

[brian (Brian Gillespie)]

You’re only half right. Ctrl+Shift+C was that way. Ctrl+V in R5 was doing _Paste Zoom S Pause Pause Move for us since the time immemorial.

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

And before you blame us for not being involved in WIP development again

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

RIP hopes and dreams. Is there at least a way to access leader horizontal justification in python?

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

Is that no longer the case for R6?

Nope, it’s no longer the case.

[Asterisk]

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.

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
Ldr.CommitChanges()

You’re off the hook with this one.

[brian (Brian Gillespie)]

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

[Asterisk]

https://mcneel.myjetbrains.com/youtrack/issue/RH-52539

Still not fixed in

https://mcneel.myjetbrains.com/youtrack/issue/RH-52277

This is not fixed either.

[brian (Brian Gillespie)]

RH-52539 is fixed in the latest Service Release Candidate

[brian (Brian Gillespie)]

I see RH-52539

RH-52539 is fixed in the latest Service Release Candidate

[Mason]

Not fixed.

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

[brian (Brian Gillespie)]

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

[Mason]

@brian
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.

[Asterisk]

Seems to be fixed here.

[stevebaer]

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.

[Asterisk]

The issue is back in 6.17

[devinperkey]

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)

[djhg]

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.

[mary (Mary Ann Fugier)]

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

Surfaces

• Display Color: Yes
  
  
• Print Color: Isocurves in Print Color / Surface in display color
  
  
  |
  
  
• Black & White (monochrome)

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.
Sincerely,
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA

[Asterisk]

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.

https://mcneel.myjetbrains.com/youtrack/issue/RH-52539

[mary (Mary Ann Fugier)]

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.
Sincerely,
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA

[Asterisk]

[mary (Mary Ann Fugier)]

Hi Asterisk,
Are you showing that shaded more is still not showing a surface in a block correctly?
I am using Rhino 6 SR21 2019-10-30.

RH-52539 issue addressed Print color, surfaces in blocks and display mode Shaded (any except Ghosed) mode and should have been fixed in 6.15.
Shaded -> Vector-> Print Color

Shaded ->Raster-> Print Color

Shaded ->Raster -> Display Color

Shaded ->Vector-> Display Color

The RH-54873 issue with Print color, surfaces in blocks and display mode Ghosted mode is still open and scheduled to be fixed in 7.0.
Ghosted -> Vector-> Print Color

Could you post a model and the ini from your display mode so I can try and duplicate this here?
My model is attached for you to try as well. My Shaded display mode is default.
surface in block - ghosted - print color issue.3dm (125.5 KB)

Let me know if I missed something here or if you see something different.
Thanks for your help.

Sincerely,
Mary Ann Fugier