Surfaces in blocks print differently than on their own?

RH-52583 is not fixed in 6.15. It’s marked Awaiting Dependency. It is fixed in an unmerged branch of 7.x to the point of being testable internally via a test command, but requires an interface change in the DimStyle and Leader properties dialogs to be completely done. That’s why it’s in 7.x instead of 6.x.

The dependency is that there was a change needed in v6 file reading of DimStyles that didn’t show up until the fix for RH-52583 that would have caused some leaders to not be editable in 6.x. That bug is fixed in 6.15 and when a SR containing that fix is out, I’ll either fix the dialog stuff or ask Alain to do it and commit the fix for RH-52583 in 7.x

@lowell according to @Asterisk this also is a regression from V5. Is it possible to fix this in Rhino 6, even though there would be a UI change?


We don’t want our money back, We really only want Rhino 6 to work as well as Rhino 5. There is a Rhino loyalty factor here.

When Rhino 6 went on sale I knew there was some issues as I had been using WIP on and off for a year or so before it became Rhino 6, and would update version as they were published. There were at times updates almost daily.

I knew there were issues when I bought the new version. I am sure I am not alone in that. I believed that they would be addressed in time and life would go one. But at this date I should be able to open any step file in Rhino 6 especially if it opens in Rhino 5 (RH-52486) as well as do other expected things that I can do in Rhino 5

That bug was reported a week ago, and contains a confidential file, so it’s not public. The bug is in progress, and should be fixed in the V6 timeframe.

I’m afraid we have no way of doing better than working on your issue within the week it comes in.

@Asterisk here’s how we got to where we are:

During the WIP phase of Rhino 6, several of our most active and vocal users (not necessarily ones on this forum) suggested that the implementation of leader text alignment in Rhino 3, 4, and 5 was bad because it didn’t map well to the way AutoCAD works. They wanted to be able to transfer files between Rhino and AutoCAD with 100% fidelity using both DXF and DWG file formats.

Rhino 3, 4, and 5 only auto-aligned leader text to the tail. AutoCAD only explicitly aligns leader text left, right or center.

The change we’re making in V7 is to add back the auto-alignment functionality for leader text. There’s some significant work to make this work right, including:

  • Figuring out default values
  • Testing compatibility with Rhino 3, 4, 5, 6 (both reading old files and saving to old files)
  • Testing compatibility with AutoCAD and other CAD products
  • Making sure the UI makes sense

Because the possibility of breaking this for other customers (who requested the change in the first place) is high, and because these features have existed in Rhino 6 for several years, we’re not comfortable making the change in Rhino 6.

Admittedly, this change is a regression for you. Had you been involved during the Rhino 6 WIP phase, you might have noticed and given us some additional feedback to get it right. I strongly encourage you to be involved in the Rhino 7 WIP development. Without your voice, we’ll continue to make Rhino work for the people who are involved - and it might not be to your liking.

1 Like

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.

Look, we love Rhino and passionate about it. With all its bugs and shortcomings we’d still choose it over the monstrosity that shall not be named here. We’ve been so swamped for the past year, that only now we are able to make a window to finally shift to R6. R6 WIP was so buggy at the time we had the opportunity to explore it (a year and a half ago) I could spend days just logging and testing all kinds of bugs. And before you blame us for not being involved in WIP development again, I’m just gonna post this here: V5 vs V6 text justification

I will be helping with R7 WIP as soon everyone (26 + potentially another 4 by the end of the year) here is not “suffering” working in R6. I want to help, 'cause Rhino is the lifeblood of our engineering department, but we’d like you to help us a little in return too.

Re: Leader horizontal justification.
RIP hopes and dreams. Is there at least a way to access leader horizontal justification in python? We already use script to plop our leaders, I can make it adjust justification. Otherwise we’d probably have to have all our leaders justified by center. It’s gonna look like ass, but oh well…

Correct. Don’t worry about backwards compatibility. We don’t care for it. We’re only prepared to move forward and onward as bequeathed by great Lenin. /s
We just want surface in blocks and not print the same.

block vs surface pdf.3dm (373.8 KB)
Shaded.ini (12.6 KB)

1 Like

I’m just catching up on this thread as I’m supposed to be on vacation :joy: It seems like some information may have been mis-interpreted. If there is a regression in functionality in V6 for any sort of printed output, we will seriously investigate and attempt to fix the bug in a V6 service release. If the bug is easy to reproduce with a simple model, then chances are we can fix this pretty quick. Holo’s draw order bug is very hard to figure out and I doubt this even worked well in V5. That doesn’t mean I’m giving up on it as I have made some tweaks to improve his situation over time, but haven’t completely fixed the issue.

We are releasing V6 for Mac “soon” which means we will have a round of service releases for Mac. Windows users will benefit from this in that some Mac fixes will also be fixes on Windows.

We are not adding new features for V6, but we are still fixing regression bugs.

any time table to release v7?

Hi - as Brian wrote above:

we don’t tend to release software on a timeline - we release it when we think it’s ready.

what can we use the rhino 6 if which have a big problem, eg. this pdf problem (can’t production) ?

Is this pdf issue affecting you? This issue affects asterisk, but there is a possibility you may not be using the same display and print settings.

I have a another problem of printing, I will post it when i sort out the information :0

It seems that all display modes are affected that aren’t wireframe or rendered.

RhinoPDF.pdf (2.9 MB)

I think this bug may actually be fixed in the latest code for the next V6 service release. We are going to double check on that before sending you off to download and install.

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