The horror the horror of exporting to pdf and illustrator

Hi McNeel Team,

Bugs with Disclaimer: this is a real horror movie. A non-comedy of errors. A mistaken identity of a rough WIP with any level of production software:

Thanks goodness I only needed this to make some Holiday custom pint glasses, not for something actually important.

Do you want me to count all the bugs that I caught here in 4 minutes? or can you do that yourselves?

Please let me know if you need the offended file.



Use RhinoPDF instead of the Adobe PDF printer driver especially if you are trying to output PDFs that you want to edit later in another app

Ok Steve, good to know. Thx. What about all the scaling output issues?

I’m jumping around all over the place right now. I only saw the first part of your video and could tell right away that Rhino PDF would probably give you easier to work with results.

I’ll need to rewatch the video to figure out the scaling issues you mention and get back to you.

Steve I looked at this some more. The scaling problem happens only in File>Export as pdf/ai. It’s not happening in File>Print (sing a PDF print driver). And the preview of a page size in that File>Export dialog is what’s broken, but the output does come out at the correct scale.

I made this other video showing you that:

@Trav can you take a look at this?

I’ve create a YT for the issue here and will see what’s up.

1 Like

Thanks @Trav, and just want to make sure that your YT only list the one issue in my second video.

There’s other major problems on my first video too:

  • dimensions, arrows and text not exporting unless exploded

  • exploding them causes flipping/mirroring

  • line quality on export gets destroyed



Hey Gustavo -

In your second video at 2:07 you show that the dimension text ends up correctly in the PDF file. Arrows also show up in the export preview dialog in Rhino. The bug is that the dimension text should also show up - RH-62040

That is expected behavior for annotations. You need to uncheck Text reads forward when viewed from behind if you need to make sure that annotations are facing the “correct” way.


Is it possible that these parts consist of arcs? If so, I think we have this one on the list as RH-44145. If you think that it might be something else, please provide a sample file.


hi Wim,

Yeah, owe need to export exactly what we see in our viewport: texts, arrows, dimension, texts, all. You miss one thing and we got nothing. And this is not rocket science this is basic basic 30-years old 2D computer stuff.

Thanks for the mirroring/flipping suggestion but that does not solve my problem. I want to have that option enable, I never want to be reading text flipped. And also I never want to explode text flipped. I also never want to export anything flipped. In fact I’m only dealing with exploding because your exports don’t work. We should be fixing that first.

But I see the problem here, in this case these two text items are showing in the opposite site of these volumes, and the front view text and the rear view text are being flipped from each other to always look correctly on a given view:

So If I explode, then either the front view or the rear view will be flipped, and out of since with the viewport specific appearance, correct? well… I exploded from the back view, so of course I want to see it correctly form the back view, not the front. Unchecking that option will not help me there, in fact I will be seeing it flipped before and after exploding. I think this should work on a WYSIWYG basis. and should pay attention to what viewport /view is active

BTW If I explode here, this is what I get:

This is ridiculous. File here before exploding: front-rear_text_gf_201218.3dm (186.4 KB)

I said this before and I’ll say it again: you guys continue shipping and selling software that is provenly untested, and I should not be the one providing you these examples and explanations. These are all things that should be solve internally, and the software we use should just work.

I see this situation getting increasingly worse, also combined with this other problem that you are all getting into new spaces (like SubD) without enough focus. So now you are doing the double whammy: shipping untested old tools + shipping new tools that barely had much thought, let alone competitive landscape awareness.

Is this the way forward for McNeel now? because it really sucks IMO.


1 Like

For me it started with the Mac version. McNeel just can keep up - never seen 33 SR before Rhino 6. I see why many software companies move to the cloud versions - one code for all platforms. And now they have to deal with M1.

A high number of service releases is a result of improvements in our development processes. We want to get quality updates and fixes to users as fast as possible so we developed a delivery cadence. Approximately every four to five weeks we deliver a new service release with stabilizing candidates for that service release published every week leading up to a new service release. Service releases contain bug fixes, new SDK features, and sometimes new critical features that users need. When a major version of Rhino gets to be about 3 years old you can expect the service release to be somewhere in the 30s. We are already on SR1 of Rhino 7 with SR2 available as a release candidate because we are following this cadence of delivery.

Sorry you’re running into bugs. I just had one added to my list from this thread for missing text in the preview. I’ll try to take a look at it this week and will hopefully have something fixed shortly.

1 Like

Just one sample - BoxEdit. It was broken many times during Rhino 6 Sr’s. Now is broken again - R7 Boxedit bad change from R6 - Rhino / Rhino for Windows - McNeel Forum.
Rhino 4 was rock solid.

Yes. I wrote about this 2 years ago:

It’s obvious at this point this is absolutely unimportant to McNeel. I gave up even reporting how broken BoxEdit is on and off. My only comment was last week about a feature request: working with any selectable SubOjbect. But what’s the point do adding features to a room that continues to be broken?

No need to apologize for that Steve. Running into bugs here and there is normal. Shipping us untested software so you offload to our businesses the work that should be handled by your business is what frustrates me.

It’s always super exciting to hear about all this future stuff like compute, and new architectures, and all that fancy stuff. But any hour of your teams’ work that’s going into that, prioritized over going into shipping software with a basic level of polish and functionally for those of us who have to work with your software, is really bad prioritization IMO.



I understand the frustration. But it’s not so simple to “test everything”. You don’t. And you don’t “fix that which isn’t broken”. Until you know it’s broken, that is.

If they now have improved the development process, it means that years ago (with all those old bugs that didn’t get fixed) now have a better chance of getting fixed. Due to adding tests as bugs occur / gets reported. I wouldn’t fix code which isn’t (known to be) broken either.

I wouldn’t try to write tests for “everything” either, simply because then you don’t get half the stuff out the door which now is shipped. And there’s this not so well known but very true saying out there regarding testing in general:

– When you say something is tested, it only means that you have tested that which you have have tested (implying: not the all the other stuff which you didn’t test).

And this is why testing is something that gradually grows as bugs are getting known/reported. You can’t and will never test everything. No one does.

Although I understand the frustration I also expect the improved development process to gradually make things better in the future. Sounds like good news, only, to me. Bugs won’t stop to pop up, but if the Same bugs stops to pop up, that will make the future brighter.

Have a nice weekend all of you!

// Rolf

Every feature added and every bug fixed in our bugtracking system goes through a process where it is tested on Windows and Mac before it is documented and announced. There are unintended consequences of fixes that may cause other bugs. There are times when a bug is very difficult to reproduce in the first place. There are times when the tester may not have the right information on what exactly to test. There are even times when we get it right.

I’m confident this process could be improved and over time we’ll figure out new ways to make these improvements.

Thanks for your input Rolf, you bring up some really good points, yet I would like to challenge the approach you listed about testing.

In our little company we have one rule: “we always check our work. And when we are done checking, before sending it to client, we checking again.”

Could we work in more things, more clients, more projects, more concepts if we didn’t spend so much time checking our work? Absolutely! Would it be more fun? Oh yeah! …checking your own work and documenting it thoroughly is boring AF. It limits our growth and it fact it makes many people who otherwise would be a good fit to our team not viable to be part of the team. Programmers are a very hot commodity and I’m sure of you put this burden on them many would just leave McNeel or never join to begin with. But there’s plenty of other people that can do this for them. QA is a thing.

There’s a level of care and craftsmanship in their work that I think it’s falling behind, or maybe as I have bigger quality issues to deal with in a production pipeline of people ‘checking their work’ I’m simply more aware of it.

I think if you are expecting your customer being the ones who constantly find out what you haven’t resolved, you are not giving them a very good service or a very good experience.

I know the bar is very low in the 3D software industry. In fact, I can’t even think of a better/viable alternative to Rhino. But some improvements in their process are overdo. For example you just can’t just keep shipping new builds where a Step/OBJ/PDF/DWG exporters/importers are broken. In any possible way. This is absolutely unacceptable. I think we need to agree on a basic level of respect to customers where the most mundane stuff that hundreds of thousands of users use every day can’t just simply be that carelessly broken.

I want them to take this 10X more seriously. And I think it’s perfectly reasonable.



I’m an ol’ QA consultant. (that’s where I got that “you tested only what you tested, nothing more”. :wink:

I won’t debate with you about the most critical functionality you depend on in your daily (as for me I mostly crunch terribly bad meshes from MRI & CT -scan, no quality check there no…). It’s ruining my old QA-mindset. :slight_smile:

But I also spent years on huge development projects (business systems though, not CAD), almost entirely without testing (as the chief designer I didn’t think I had the time…) but strangely enough, the huge system worked more or less flawlessly after 6+ yrs of development. But I had the whole system “in my head”. which meant I could predict silly behavior, both from users and from code. It still was a wonder how it worked so well. But, CAD software is different from business systems. I can’t imagine a single developer holding the entire codebase of Rhino “in their head” so that they can predict all consequences from changes and additions.

Anyway, software development is still a bit of black magic. Except for it doesn’t work better if you put a spell on it… :slight_smile:

Have a nice weekend!

// Rolf

I know you know this Rolf, but for others’ benefit:

There’s a heck of a lot of science that can be applied to it these days.

One piece of science involves making testing the primary focus of your effort rather than an adjunct to coding - as embodied in the culture known as test driven development (TDD). In that culture you write an automated test of behaviour that the software must pass, write basic code which may fail that test, extend the code until the test is passed, then add another test and extend the code until both tests are passed, then keep adding tests, extending and passing. If at any point you fail an older test you have to fix that. The idea of passing all the old tests as well as the new is known as regression testing. Your tests are the specification for the software. Anything not covered by a test is not part of the specification and that behaviour is not guaranteed. Your specification is a contract with the users of your software.

In this culture a piece of software cannot be released at any time when one or more test fails. Therefore a new release cannot break something that previously worked.

TDD dates back to the late 90’s (embodying much earlier concepts).



TDD is and sounds ideal. But, the basic problem remains - namely no matter what strategy or concept you are following - you are still testing only that which you are testing. That’s a brutal fact with consequences.

It takes time to “cover up” your tracks (bugs) with a test you didn’t predict was needed. It’s just an everyday reality in software development.

If the system can be grasped by a few persons, testing may be covering potential mishaps earlier, if it’s more complex, and structured testing applied only late in the product cycle, well, then you’re going to have bugs keep popping up, no matter the strategy.

Again, It’s only what you test which is tested. How you get to the point where the testing is extensive enough, that’s a different story altogether. And much different from case to case. :slight_smile:

// Rolf