CAD Lines randomly disapearing during PDF Export?

Hi all,

I am having a really odd bug pop up when exporting PDF of CAD lines? I wonder if anyone can help me solve or recommend a solution?


I have a CAD floor plan in my Rhino scene. Just a normal CAD block of lines. Noting too fancy. When I make a Layout view, and ExportAll everything works as expected, and the PDF outputs the line-work just fine.

CAD Plan in Layout View:

So far so good:

So that’s all working as expected…no trouble there.


The issue occurs when I bake some GH hatches to the Rhino scene. As soon as I do that, now my PDF exports with only a semi-random selection of the CAD lines? (I say semi-random as they are the same lines each print, but its not clear what is unique about these particular lines compared to the rest?)

Add Hatches to the Scene:

Now CAD lines randomly disappear in my PDF:

Additional Info:

This is not the first time I have run into this problem. However in then past, my solution was to go the Layout Detail-View, double-click Detail-View and select the CAD-Block object, explode the block WHILE STILL IN THE LAYOUT (that part was important for this to work), and then re-make the block (again, while in the Layout, not in the model). In the past, this seemed to fix this issue, but for some reason now this workaround is no longer working for me in this case? I’ve tried exploding and re-making the block several times now, all with no luck.

Also: Note that If I turn off the layers that the hatches are on, the export issue still occurs, however if I fully delete all the hatches out of the scene, then the PDF export goes back to working properly and exporting all of the CAD lines once again.


  • Mac M1 / ARM
  • MacOS Monterey 12.5.1
  • Rhino v7.34.23267.11002, 2023-09-24

Any thoughts or ideas about how to export this PDF properly are much appreciated!

(oh, and also: this seems to be a problem with the Vector PDF output, not the Raster PDF output)

FYI, just to update:

This is still an issue with printing PDF on MacOS (printing Blocks with CAD lines is unreliable / irregular). The same file / config prints as expected on Windows OS (all CAD lines appears properly, even in Vector mode)


PDF printing is remarkably difficult, at least for Rhino. Would you be willing to download the Rhino 8 evaluation from and let us know if it continues to be an issue in Rhino 8?

Also, if you have a 3dm file that you can attach that reproduces the problem, we’d love to see it. We don’t do a ton of production drafting as software developers, so the chances of us being able to model a scene that reproduces the bug is quite low.


1 Like

Hi @brian ,

Yes you bet: not a problem. In Rhino-8 things behave in an even different way though (just to make it even a bit more complicated :wink: ). For reference, I’ve tried to attach a simplified example Rhino-7 & Rhino-8 files, in case that is helpful to illustrate the issue.


A architectural scene with a base CAD underlay (nothing huge, a single floor-plan is ~6-8 Mb when saved in DXF format), and some colored Hatches (usually to illustrate ‘rooms’ or spaces). The goal is to get my Mac PDF export to function like on Windows PDF print where I can export a PDF which shows the colored hatches, and the line-work, all as vector.

Example output from Windows :white_check_mark:
(Working: all the CAD lines show, even where they are over the hatches):

Case 1a: Rhino-7 | Raster :x:

In Rhino-7, when I export a PDF as ‘Raster’, everything looks more or less as intended. The lines all show, and the lines overlap the hatches, so ever the ones ‘inside’ the hatches show up nicely. Except: its raster, so the file sizes are very large, and any small text is unreadable. The text problem is especially a issue as my use-case here are large architectural plans with many room tags and small text items that need to be readable when zoomed in.

Case 1b | Rhino-7 | Vector [Exploded CAD] :x:

In Rhino-7, when I EXPLODE the CAD plans into regular curves in the scene, they do print to PDF as vector. The hatches do occlude the lines in this case, but the ones on the ‘outside’ do print at least. However: the Rhino files are un-usable in this manner (with the CAD plans exploded) due to the normal display performance issues in RH7-Mac.

Case 1c | Rhino-7 | Vector [Block CAD] :x:

In Rhino-7, when I have the CAD plans as BLOCKS, the Rhino file works much, much, much better (muuuuuch faster, more responsive) but then they only print irregular / random lines instead of the entire line set.

Case 2a | Rhino-8 | Raster :x:

When I open in Rhino-8, Raster print works as in Rhino-7. But as explained above, raster print is not really a viable solution for my use-cases.

Case 2b | Rhino-8 | Vector [Exploded CAD] :x:

As in Rhino-7, when I EXPLODE the CAD plans, the lines do print. The Hatches occlude the CAD lines where they overlap (same as in Rhino-7), but at least the outer lines do print.

Case 2c | Rhino-8 | Vector [BLOCK CAD] :x:

In this case, the Block lines do not print at all. Nothing prints in any way. Even the ‘irregular’ CAD lines that printed in Rhino-7 are not printed. All I get are the hatches in this case.


Doing some experimentation, I actually believe that the main issue here is a problem with CLIPPING PLANS not working with BLOCKS properly when exported to PDF. In all the scenarios above, I use clipping planes to isolation one floor level at a time (my normal use-case is a tall building with several floors) and the clipping planes are used to isolate, then print one PDF for one floor level at a time. I believe that these clipping planes are NOT working properly with the Blocks and this is what is causing these issues. I have no idea if I’m actually right about that, but it appears to be the case, just messing around with it.

Any thoughts or suggestions are if course appreciated.


  • Macbook 2021, Apple M1 Max
  • macOS Ventura 13.6.1 (22G313)
  • Rhino Version 7 (7.34.23267.11002, 2023-09-24)
  • Rhino Version 8 (8.2.23339.13002, 2023-12-05)

Example Files

all the best,

1 Like

FYI, I believe I have found the source of this issue:


1 Like

Thanks for digging into this! I’m going to assume the other thread will handle this issue.

Hi @brian , yes I think so? It seems to me this was the issue in this case.