V6 Goal: True PDF Export

I’m excited to let you know about a new feature that just showed up in the latest V6 WIP (Jan. 25th build).

Rhino 6 writes PDF files without the need of a printer driver.

This feature is currently only available in File->Save As… I will be integrating this into the Print command in the future. Here are some of the key new features.

No printer driver required
As I already mentioned, this feature is independent of any 3rd party printer driver. You shouldn’t have to try and figure out which printer driver is best for Rhino since you shouldn’t have to use a printer driver.

Improved Curve Output
Rhino’s printing system traditionally breaks down curves to polylines which fit the original curves to a certain dot tolerance. This resulted in PDF files with very dense polylines. For printing to paper this is fine, but if you planned to later open and edit the PDF file downstream in something like Illustrator you ended up with geometry that wasn’t extremely useful. The new PDF exporter converts curves to paths that are composed of either line segments or cubic beziers fit to a dot tolerance when possible. This results in much cleaner and easier to use geometry.

Improved Hatch Output
Rhino’s printing system traditionally prints solid hatches as a series of filled triangles. Again, fine for printing to paper but useless if you are attempting to edit the resulting PDF. The new PDF exporter generates paths with appropriate winding rules to generate true filled regions that are easy to work with for editing.

SDK Access
Previously, the only way to automate generation of PDFs was through scripting of the Print command which could be considered painful at best. The new PDF exporter focuses on putting the SDK first by being a simple plug-in which directly uses a couple classes in RhinoCommon to do the work. Developers should be able to use these classes to generate custom PDFs; be it a single PDF with 1000 pages or 1000 single page PDFs. The following python script is a sample of this new functionality.

import Rhino
import scriptcontext as sc
import System.Drawing
import rhinoscriptsyntax as rs

# create a new PDF document
pdf = Rhino.FileIO.FilePdf.Create()
dpi = 300
size = System.Drawing.Size(8.5*dpi,11*dpi)
settings = Rhino.Display.ViewCaptureSettings(sc.doc.Views.ActiveView, size, dpi)

# add 1 or more pages based on ViewCaptureSettings

#write the pdf file to disk
filename = rs.SaveFileName()

What Next?
Please try out this new feature and let me know what you think could be improved upon and what appear broken. I still need to integrate this with the Rhino print dialog and improve on the SDK access, but there are probably plenty of areas where this functionality could be improved. As much feedback as possible is appreciated. Thanks!



It appears that closed curves are opened up in the process of saving as PDF.
In this picture, native Rhino PDF is on the left; output from a PDF writer on the right.

Else, it would be nice to have paper sizes available but perhaps that will come when this is integrated with the print dialog?
The way it works now is like what is available when exporting to WMF. To get the size that I want to use I always need to get the bounding box of the objects that I want to export and then get the dimensions thereof. Then insert these in the export dialog. I wish there was a way to set these differently. In the View and Output Scale part of the export dialog, you can set a window that sets the view. Couldn’t that be used to also set the size?

Thanks Wim for checking this out so fast. I’ve added a bugtracking issue for closing curves at

Yes, the print dialog will include a bunch of paper sizes, but that doesn’t mean the PDF exporter shouldn’t also. I made also made a bug for this at

I’m not sure I understand what you are asking for here.

I remember trying to explain this a few years ago :blush:

This is a general thing when it comes to printing and export of 2D ‘stuff’ - be it bitmap or vector.
The general aim is to just export what is needed, without extra borders / empty space. When I get into the print or export dialog box [Stage 1 - Destination] I have to decide about a width and height measurement that - to me - just are numbers that are hard to relate to what I need to get out. I never know how to deal with that and basically need to setup geometry in the model to help me out: bounding box and dimensions. My default template has a WMF layer (no-print) and dimension style just to help me out here.

In the second stage of the export / print, I have to set the view. Here, we have several options that help the user: Viewport, Extends, and Window. Here I can visually decide a width and a height.

To me it should be possible to get this width and height into the destination fields.

As it is now, that dialog doesn’t make sense to me (and has never done). When I’m not exporting / printing to a pre-defined size that makes sense (e.g. A3), a width and height that is not related to the width and height of what I set to be the view doesn’t compute (to me). At least when it comes to the ratio.

Not sure if that helped making it more clear…

This is good news!


Great news!
Does this mean we can wish for 3D pdf export in the future?


Thanks Steve Great jobs.
VittorioVentaglio.pdf (30.6 KB)

1 Like

Hi Steve,

this is great! Thanks so far.

What’s next?
Pictures already export fine. Wallpapers don’t work.
Nice would be an option to export the current view as a background in any render mode.

Also it would be great to have the layers in the PDF, similar to the .ai export.

Thanks and best regards,

No, you have used up all of your wish credits and can never wish for anything ever again :smiling_imp: Of course you can wish for this. It is possible for us to add built-in 3D PDF support, but it seems like a pretty significant project and a little unrelated. This specific project is focused on making high quality 2D multi-page PDFs both through the export plug-in and the SDK. I would imagine the 3D PDF work would be done in a separate project.

Raster support is something that still needs some work which is why wallpapers aren’t working and a raster generated page will also fail. This shouldn’t be too hard to get added, I have just been focused on the vector output for starters since it seemed that the vector quality has always been feature that needed the most work.

I would imagine that this is where improvements in the SDK will make things like this possible.

I agree and made a feature request issue for this.
It isn’t my highest priority right now since I want to make sure you can get a high quality PDF for right now. New features like layers, watermarks, and signing seem to be a little further out in the future.


Hmm… I may be beginning to understand. Do you want the size of the page to be the same number of dots in the width and height as there are pixels in a viewport?

  • Not the viewport, no. The aspect ratio of the viewport will most likely be wrong. I am not pulling the borders of a viewport to get the export I need. I get the aspect ratio from the bounding box.

  • I tend to use the same number as the units in the model but I guess that pixels might do the job. If the dimensions of the model are either ridiculously high or low I just go down or up one order of magnitude. Most often, the result will be used to insert into a word document or a powerpoint presentation. Sizes that “make sense” in relation to this is what I aim for…

Steve’s probably already got it, but I’m having a tough time visualizing what you’re saying. Would it be a big deal to prepare some screen shots and pseudo-paper layouts to show what you mean? Tying together what you are trying to accomplish with respect to paper size in inches (mm), printer resolution, viewport pixels, model extent and aspect ratio, screen resolution, etc? And, of course, what you’d like to see in a GUI to make it easy.

I’m still confused too and this is probably a case where a mock up would really help. I’ve got the feeling that implementing this request wouldn’t be too hard once I understand it.

Very nice addition, I will be happy to make my SVG exporter UI quite the same as yours. It’s cool that you have feedbacks, I was not so lucky :frowning:
Some questions
How is done UI and folding panel. I used Windows Forms in Visual Studio 2015
How to get geometry of annotations ?

Some comments
When there is a point it appears as a circle in the viewer and a rectangle in Acrobad Reader DC 2015.
I understand you wanted a true WYSIWYG, also for selected curves ! but when there are surfaces they are not (yet?) exported but they are visible in Viewer. Visible on artistic and copied as curves with isocurve on pdf. On SVG I choose to export the border and fill the interior, and also add transparency.
Arrow of dimension visible on Viewer not on PDF

Keep the good work

1 Like

Just as an FYI; I also implemented an SVG exporter at the same time as when I wrote this PDF exporter. This should be showing up soon in the V6 WIP. The SVG export will be available in the next WIP’s RhinoCommon SDK. I’ll write a separate post once this feature becomes available.

Technical and artistic modes are actually raster operations and will be supported in the PDF exporter once I have rastet output supported.

Thanks for the note on points. I’ll get that added to the bugtracking system


Thanks for the information, so I will not work more on my SVG exported and keep it for Rhino 5.0. It was useful for me to get some lasercut from Sculpteo.

To come back on PDF do you plan to output surface flattened made with filled path ?

Another loosely related issue that should be considered is the matter of printing a model at a scale that requires multiple sheets with registration marks for proper alignment. The way the GUI for this is implemented in normal printing could use some serious additional love and, of course, should be carried over to pdf. Probably not needed in SVG.

You may still find it useful to customize. RhinoCommon will have a function that creates an SVG from ViewCaptureSettings. This function will return an XmlDocument instance that you could further adjust before saving.

Solid hatches are exported as filled paths. Surfaces will either be wires in vector output or a bitmap image in raster output